Nicolas 8f75a47b23 ci(test): serialise vraiment le job test entre runs concurrents ... Deux jobs `test` qui se chevauchent partagent un seul conteneur `--name postgres` sur le reseau docker du runner (pas de bloc `services:`) : leurs `prisma migrate deploy` + `seedReferenceData` (beforeAll racine Mocha) rentrent en collision - "Unique constraint failed on (key)", "No pending migrations" alors qu'il en reste, decalages d'id tech_step/diet cassant des assertions sans rapport ; et meme en dehors de ca ils s'affament mutuellement en RAM/CPU (chacun entraine aussi un modele spaCy) jusqu'a ce que resetDatabase() depasse le timeout de hook Mocha (10s) et que ca cascade. Touche a repetition ce mois-ci (PR #47, #53, #54, et de nouveau aujourd'hui sur #93/#94/#95), a chaque fois resolu par une relance a vide une fois le runner plus calme - jamais un vrai bug de la PR concernee. `concurrency:` (le vrai correctif GitHub) est silencieusement ignore par ce Forgejo (9.0.3, arrive en v14/Gitea 1.26). Un objet de verrou (reseau, conteneur, fichier) fuirait : ce runner (forgejo-runner v3.5.0) n'execute pas les steps `if: always()` suivant un step en echec, donc pas de liberation fiable en fin de job. A la place : s'appuyer sur ce que le runner nettoie toujours lui-meme - le conteneur du job (supprime en succes, echec et annulation) - et attendre tant qu'un job `test` de task id inferieur tourne encore. Le plus petit id part en premier, donc deux jobs demarres ensemble ne peuvent pas se bloquer mutuellement ; rien a liberer explicitement. Trois ajouts, purement additifs (aucune ligne existante modifiee) : - nouveau step "Wait for any earlier test job" (poll docker ps, plafond ~25min) juste avant le demarrage de Postgres ; - `timeout-minutes: 45` sur le job (couvre le temps d'attente eventuel + garde-fou si le job reste bloque, vu l'absence de --exit sur Mocha) ; - le nettoyage `docker rm -f postgres` existant balaie aussi les conteneurs `postgres-<suffixe>` orphelins (residus d'un essai anterieur de nommage par run, deja abandonne sur cette meme branche, jamais nettoyes faute de teardown fiable). Travail deja fait et documente par une session precedente (branche claude/magical-stonebraker-5dc636, verifie fonctionnel en run 130 : "12x waiting for earlier test job(s)... puis proceeding") mais jamais fusionne - retrouve et applique aujourd'hui en diagnostiquant la meme contention sur trois PR en cours (#93/#94/#95). Verification : impossible de re-simuler la course en local (pas de second runner ici), mais le diff est purement additif et applique sans le moindre conflit sur l'etat actuel de main - les trois commits de ci.yml survenus depuis (upload-artifact v3, bit gradlew, build-android) touchent un job entierement different du fichier. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>		2026-09-07 13:42:23 +02:00
..
workflows	ci(test): serialise vraiment le job test entre runs concurrents	2026-09-07 13:42:23 +02:00