Des jobs meurent en ~15 secondes sur pip install -e ., avec une erreur qui dit que le tool-cache Python du runner porte l'etat d'un job precedent — sur des runners etiquetes coursia-ephemeral.
Le symptome, verbatim
Installing collected packages: ict-series
Attempting uninstall: ict-series
Found existing installation: ict-series 0.1.0
Uninstalling ict-series-0.1.0:
ERROR: Could not install packages due to an OSError: [Errno 2] No such file or directory:
'/opt/hostedtoolcache/Python/3.9.25/x64/lib/python3.9/site-packages/__editable__.ict_series-0.1.0.pth'
##[error]Process completed with exit code 1.
Lecture : pip trouve une installation preexistante d'ict-series dans le site-packages du hostedtoolcache du runner, entreprend de la desinstaller, et le fichier .pth que le RECORD de cette installation reference n'existe plus. L'etat est donc a la fois persistant (il survit d'un job a l'autre) et incoherent (RECORD et disque divergent).
Un runner reellement ephemere ne peut pas produire cette erreur : il n'a rien a desinstaller.
Occurrences mesurees
| Run |
Job |
Runner |
Horodatage |
33828593263 |
100886494483 |
myia-po-2024-linux-docker-5 |
2026-09-04 |
33841162044 |
100937271413 |
myia-po-2024-linux-docker-6 |
2026-09-04T06:47:05Z |
n = 2 en ~4 h, les deux sur le parc Linux docker de po-2024, aucune sur les runners d'ai-01 executant le meme workflow. C'est peu pour affirmer une exclusivite : je le note comme une localisation apparente, pas comme une mesure de taux.
Biais de mesure a connaitre — le balayage gh run list --status failure rate une partie des occurrences : la seconde ci-dessus vit dans un run dont la conclusion globale est cancelled (l'autre job du run a ete tue par cancel-in-progress pendant que celui-ci echouait). Un comptage par conclusion de run sous-estime donc structurellement ce defaut ; il faut descendre au niveau job.
Pourquoi ca compte au-dela d'une PR
C'est un rouge non reproductible et non imputable : il tombe sur n'importe quelle PR dont la CI fait un pip install -e ., il ne depend pas du code de la PR, et il ressemble a un echec de la PR. Une lane qui le recoit cherche dans son propre travail — c'est exactement ce qui vient d'arriver sur #14559, ou j'ai moi-meme mal attribue le rouge avant de lire le log du job.
Il se combine mal avec cancel-in-progress : sur un parc charge (file mesuree a ~48 min entre creation et demarrage d'un run ICT ce matin), une relance vit assez longtemps pour se faire annuler par l'entree suivante dans le groupe de concurrence, si bien que la vraie cause reste invisible plusieurs tours.
Ce qu'il faut verifier (sur po-2024, cote hote)
- La definition du conteneur runner :
/opt/hostedtoolcache est-il un volume persistant partage entre conteneurs successifs ? C'est le montage qui explique tout le reste.
- Le mode de recyclage : les conteneurs sont-ils lances avec
--ephemeral cote config.sh, ou seulement etiquetes coursia-ephemeral ? L'etiquette est declarative, elle n'impose rien.
- Si le volume est partage deliberement (gain de temps sur
setup-python), alors le cache doit etre en lecture seule pour les jobs, ou le pip install doit viser un venv de job (python -m venv "$RUNNER_TEMP/venv") au lieu d'ecrire dans le toolcache.
Pistes de correction, par cout croissant
(a) Rendre le pip install -e . d'ict-tests.yml (et de ses freres) non destructif du toolcache : creer un venv par job. Repare la classe pour les workflows concernes, ne touche pas au parc.
(b) Ne pas partager /opt/hostedtoolcache en ecriture entre conteneurs sur po-2024. Repare la classe pour tous les workflows, demande un geste sur l'hote.
(c) Purger le toolcache incoherent une fois et attendre. Ne repare rien : l'etat se reconstituera au prochain pip install -e ..
Je penche pour (a) puis (b) : (a) est portable et se livre en PR ; (b) traite la cause mais appartient a l'hote.
Acceptance
- La cause est etablie firsthand : dire si
/opt/hostedtoolcache est un montage partage sur les conteneurs runner de po-2024, avec la ligne de configuration citee.
- Le workflow ICT (au minimum) n'ecrit plus dans le
site-packages du toolcache — venv par job, ou equivalent.
- Controle positif : deux runs consecutifs du meme workflow sur le meme runner (
myia-po-2024-linux-docker-*), le second devant reussir la ou il echouait. Un seul run vert ne prouve rien : le defaut ne se manifeste qu'au deuxieme passage sur un cache deja ecrit.
- Si le partage est deliberement conserve, l'ecrire dans la doc du parc avec la contrainte qu'il impose aux workflows.
Note connexe (a ne pas fusionner ici)
ict-tests.yml porte concurrency: group: ict-tests-${{ github.ref }} + cancel-in-progress sur pull_request. C'est sain en regime nominal, mais sous file longue une relance de job se fait annuler avant de conclure, et le seul geste qui produit un run complet devient une nouvelle tete. C'est un cout de churn impose aux lanes ; ca merite son propre examen, pas un elargissement de cette issue.
Des jobs meurent en ~15 secondes sur
pip install -e ., avec une erreur qui dit que le tool-cache Python du runner porte l'etat d'un job precedent — sur des runners etiquetescoursia-ephemeral.Le symptome, verbatim
Lecture :
piptrouve une installation preexistante d'ict-seriesdans lesite-packagesdu hostedtoolcache du runner, entreprend de la desinstaller, et le fichier.pthque le RECORD de cette installation reference n'existe plus. L'etat est donc a la fois persistant (il survit d'un job a l'autre) et incoherent (RECORD et disque divergent).Un runner reellement ephemere ne peut pas produire cette erreur : il n'a rien a desinstaller.
Occurrences mesurees
33828593263100886494483myia-po-2024-linux-docker-533841162044100937271413myia-po-2024-linux-docker-6n = 2 en ~4 h, les deux sur le parc Linux docker de po-2024, aucune sur les runners d'
ai-01executant le meme workflow. C'est peu pour affirmer une exclusivite : je le note comme une localisation apparente, pas comme une mesure de taux.Biais de mesure a connaitre — le balayage
gh run list --status failurerate une partie des occurrences : la seconde ci-dessus vit dans un run dont la conclusion globale estcancelled(l'autre job du run a ete tue parcancel-in-progresspendant que celui-ci echouait). Un comptage par conclusion de run sous-estime donc structurellement ce defaut ; il faut descendre au niveau job.Pourquoi ca compte au-dela d'une PR
C'est un rouge non reproductible et non imputable : il tombe sur n'importe quelle PR dont la CI fait un
pip install -e ., il ne depend pas du code de la PR, et il ressemble a un echec de la PR. Une lane qui le recoit cherche dans son propre travail — c'est exactement ce qui vient d'arriver sur #14559, ou j'ai moi-meme mal attribue le rouge avant de lire le log du job.Il se combine mal avec
cancel-in-progress: sur un parc charge (file mesuree a ~48 min entre creation et demarrage d'un run ICT ce matin), une relance vit assez longtemps pour se faire annuler par l'entree suivante dans le groupe de concurrence, si bien que la vraie cause reste invisible plusieurs tours.Ce qu'il faut verifier (sur po-2024, cote hote)
/opt/hostedtoolcacheest-il un volume persistant partage entre conteneurs successifs ? C'est le montage qui explique tout le reste.--ephemeralcoteconfig.sh, ou seulement etiquetescoursia-ephemeral? L'etiquette est declarative, elle n'impose rien.setup-python), alors le cache doit etre en lecture seule pour les jobs, ou lepip installdoit viser un venv de job (python -m venv "$RUNNER_TEMP/venv") au lieu d'ecrire dans le toolcache.Pistes de correction, par cout croissant
(a) Rendre le
pip install -e .d'ict-tests.yml(et de ses freres) non destructif du toolcache : creer un venv par job. Repare la classe pour les workflows concernes, ne touche pas au parc.(b) Ne pas partager
/opt/hostedtoolcacheen ecriture entre conteneurs sur po-2024. Repare la classe pour tous les workflows, demande un geste sur l'hote.(c) Purger le toolcache incoherent une fois et attendre. Ne repare rien : l'etat se reconstituera au prochain
pip install -e ..Je penche pour (a) puis (b) : (a) est portable et se livre en PR ; (b) traite la cause mais appartient a l'hote.
Acceptance
/opt/hostedtoolcacheest un montage partage sur les conteneurs runner de po-2024, avec la ligne de configuration citee.site-packagesdu toolcache — venv par job, ou equivalent.myia-po-2024-linux-docker-*), le second devant reussir la ou il echouait. Un seul run vert ne prouve rien : le defaut ne se manifeste qu'au deuxieme passage sur un cache deja ecrit.Note connexe (a ne pas fusionner ici)
ict-tests.ymlporteconcurrency: group: ict-tests-${{ github.ref }}+cancel-in-progresssurpull_request. C'est sain en regime nominal, mais sous file longue une relance de job se fait annuler avant de conclure, et le seul geste qui produit un run complet devient une nouvelle tete. C'est un cout de churn impose aux lanes ; ca merite son propre examen, pas un elargissement de cette issue.