Repository navigation
fix(ci,#17628): remettre en CI les 5 tests session_hygiene (étape séquentielle dédiée) - #17736
Conversation
…uentielle dediee) Les 5 tests de test_session_hygiene.py ne tournaient JAMAIS en CI : leur skipif de module saute des que CI=true ET RUNNER_OS=Linux ET PYTEST_XDIST_WORKER est pose -- or le pool n'a que des runners Linux self-hosted WSL et l'etape pytest lance tout sous `-n 4 --dist loadscope`. La condition matchait donc tout run du job (mesure du 2026-09-24, job 107202539829 : 14981 passed, 103 skipped -- le vert ne prouvait rien pour ces 5). Le skipif autorise deja le run sequentiel (PYTEST_XDIST_WORKER absent) : aucun changement du predicat. Ajout d'une etape dediee qui relance le fichier SEUL et SANS `-n`, ce qui desamorce la saturation RLIMIT_NPROC du cumul de subprocess git (cause reelle du skip, #17496 / b8a633f) tout en rendant la couverture a l'organe session_hygiene.py (#16736). Retire aussi la marque xdist_group(name="serial-git") : elle n'est operante que sous --dist loadgroup, qu'aucun job n'utilise (loadscope cote job, aucun --dist par defaut dans pytest.ini) -- inerte partout. L'isolation visee est desormais obtenue par l'etape sequentielle. Controles mesures (post-fix) : - CI=true RUNNER_OS=Linux, sequentiel -> 5 passed (correctif) - CI=true RUNNER_OS=Linux + worker xdist -> 5 skipped (avant) Closes #17628 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
Preuve Linux declaree au body : le run CI de cette PR a execute l'etape nouvelle Session hygiene tests, sequential (5) -> |
Path-collision (organ #13359/#13615)Cette PR #17736 (
Le verdict terminal (#15578) signale qu'un cote de la paire est deja sur |
|
[ADJOINT PREFLIGHT] |
Grain: MED/tooling -- lane myia-po-2026:CoursIA -- prev: MED/notebooks #17694
#17628 — les 5 tests
session_hygienene tournaient jamais en CILe fait, re-mesuré firsthand
gh run view --job 107202539829 --log→14989 passed, 103 skipped(conclusionsuccess). Ce chiffre de l'issue est exact au chiffre près : le vert du jobScripts Tests (CPU)ne prouvait rien pour les 5 tests descripts/tests/test_session_hygiene.py.Cause : leur
skipifde module saute dès queor le pool n'a que des runners Linux self-hosted WSL, et l'étape pytest lance tout sous
-n 4 --dist loadscope— la condition matchait donc tout run du job.Correctif — la voie 1 de l'issue (aucun changement du test)
Le
skipifautorise déjà le run séquentiel : sans-n,PYTEST_XDIST_WORKERest absent, donc la condition ne matche pas. Le correctif est donc d'une seule étape additive dans.github/workflows/scripts-tests.yml:Elle relance le fichier seul et sans
-n, ce qui désamorce la saturationRLIMIT_NPROCdu cumul de subprocess git (cause réelle du skip, #17496 /b8a633f153) tout en rendant la couverture à l'organescripts/coordination/session_hygiene.py(#16736).if: always()comme les étapes de plancher voisines : même suite principale rouge, on veut le verdict nommé de ces 5 tests plutôt qu'un silence.Critères d'acceptation (les 2, et où ils sont couverts)
passed(passkipped) dans un run CI du jobxdist_groupest opérante (loadgroup) ou retirée si inerteloadgroupn'apparaît dans aucun job (grep -rn loadgroup .github/ scripts/ pytest.ini→ 0),pytest.inine pose aucun--distpar défaut, et cette marque est la seule du dépôt. Sous--dist loadscopeelle était inerte. La rendre opérante exigerait de basculer un job enloadgroup, qui re-planifie toutes les suites — le workflow documenteloadscopecomme porteur pour d'autres modules. L'isolation visée est de toute façon obtenue autrement par l'étape séquentielle.Preuve — contrôles positif ET négatif (pas un vert de complaisance)
Les deux directions ont été mesurées, en simulant les variables du runner Linux :
CI=true RUNNER_OS=Linux, séquentiel5 passeden 5.99 s ← le correctif produit l'effet vouluCI=true RUNNER_OS=Linux PYTEST_XDIST_WORKER=gw05 skippeden 0.07 s ← la panne d'origine, reproduiteLe second contrôle est celui qui compte : il falsifie l'idée que ces tests tournaient — ils étaient bien sautés sous xdist, et le correctif ne fait pas que « passer au vert », il change la nature de l'exécution.
Limite honnête. Je n'ai pas de runner Linux WSL local : les deux mesures ci-dessus portent le jeu de variables du runner, pas son noyau. Le vert Linux réel sera établi par le run CI de cette PR — l'étape s'y exécute, donc si la RLIMIT_NPROC frappait encore en séquentiel, le run serait rouge et le dirait. C'est auto-référentiel mais c'est la preuve disponible ; je le déclare plutôt que de le taire.
Note de transparence
Le message de commit
49fd0072fccite « 14981 passed » — coquille de ma part : la mesure vérifiée est 14989 (ci-dessus, relue dans le log du job). Le chiffre juste est celui de ce body ; le commit n'a pas été amendé (protocole : pas de réécriture d'historique).Périmètre
2 fichiers, +31/−3. Aucun notebook, aucun catalogue.
Closes #17628— les deux critères sont couverts.🤖 Generated with Claude Code