Evitar concurrencia al aplicar pull-requests #178

Activity

1. ecarreras commented on Oct 5, 2026

   

   ecarreras

   on Oct 5, 2026

   MemberAuthor

   More actions

   @giscebot analitza quines opcions tenim per fer això

   👀React with 👀1Reacted by GISCE Bot
2. giscebot commented on Oct 5, 2026

   

   giscebot

   on Oct 5, 2026

   Contributor

   More actions

   He revisat el flux actual. check_am_session() no resol la concurrència: és un TOCTOU (dues execucions poden passar el check abans que cap comenci) i, amb --as-diff, git apply no crea cap estat que la segona execució pugui detectar.

   Veig tres opcions:

   1. Lock remot amb flock (recomanada). Obrir una sessió SSH dedicada que executi flock -n <git-common-dir>/apply_pr.lock i mantingui el descriptor obert durant tot el deploy. La sessió ha de continuar viva mentre les altres connexions Fabric fan upload/apply/resolució manual/commit/unstash. En acabar, es tanca al finally; si mor sastre, SSH o la màquina client, el kernel allibera el lock automàticament. No depèn de detectar ni netejar locks zombis.
   2. mkdir/fitxer creat atòmicament. És molt més fàcil d'integrar amb Fabric 1 i permet guardar PR, usuari, host i timestamp, però si el client mor queda bloquejat indefinidament. Un TTL automàtic és perillós perquè --reject pot estar legítimament hores esperant resolució manual; caldria una ordre explícita de status/unlock.
   3. Lock local al client. No serveix: no evita concurrència des d'una altra màquina o runner.

   L'abast correcte del lock és per checkout remot, no per PR: clau host + git rev-parse --git-common-dir. L'adquiriria després dels checks/prompts previs però abans de marcar pending i pujar patches, i l'alliberaria en un finally exterior, només després de git apply/git am, la resolució de --reject, commit, stash pop i actualització final de l'estat. Tant --as-diff com git am haurien d'usar el mateix lock; confiar només en .git/rebase-apply deixa igualment una finestra de cursa i no cobreix operacions auxiliars.

   Proposta d'implementació petita: un context manager RemoteRepositoryLock amb acquire/release, error immediat que mostri qui té el lock, i tests que provin (a) exclusió entre dos processos, (b) alliberament normal, (c) alliberament en excepció i (d) alliberament quan es talla la sessió SSH. Abans de codificar faria un spike curt amb la versió actual de Fabric/Paramiko per validar que podem conservar un channel SSH dedicat sense compartir estat thread-local; si això resulta fràgil, triaria mkdir amb unlock explícit i metadades, no TTL automàtic.

   També cal resoldre el path real amb git rev-parse --git-common-dir (worktrees inclosos) i citar/escapar el path; no construir el lock només amb repository.
3. giscebot commented on Oct 5, 2026

   

   giscebot

   on Oct 5, 2026

   Contributor

   More actions

   Implementat a #179.

   El canvi adquireix un flock remot per checkout (derivat de git rev-parse --git-common-dir) i el manté en un canal SSH dedicat durant tot el procés: upload, git apply/git am, resolució manual amb --reject, commit i actualització d'estat. En tancar-se el canal —també per error o caiguda del client— el kernel allibera el lock.

   Validació: 24 tests en Python 3 i 4 tests específics en Python 2, incloent una prova amb dos processos flock reals que comprova exclusió i reutilització després d'alliberar-lo.