Repository navigation
ci(runners): Golden-set execution (H.7 P3) -- "No module named 'pandas'" selon le slot, un meme head vert ou rouge #18499
Description
Le fait
Sur la PR #18483 (head cefc5cdc), le check Golden-set execution (H.7 P3) est sorti 4/8 rouge, avec en In[1] d'une cellule d'imports preexistante :
ModuleNotFoundError: No module named 'pandas'
La meme tete est verte sur un placement ulterieur du meme check : au head courant 9148a107a9, Golden-set execution (H.7 P3) = success a 2026-09-29T21:50:53Z (releve sur commits/9148a107a990/check-runs).
Un meme job, meme workflow, meme tete, vert ou rouge selon la machine qui le prend : c'est la signature d'un rouge d'environnement, et il n'est pas imputable au diff de la PR (aucune ligne du log ne nomme son contenu ; la cellule fautive est preexistante).
Ce que ce n'est pas
- Ce n'est pas le diff de feat(notebook-python,#18207): dispositif d'auto-evaluation -- module partage, tests, pilote sur 02-ML-Cours 2.1-2.6 #18483 : la classe est reconnue environnementale par la review structurelle de NanoClaw elle-meme (
clusterManager-Myia, review du 2026-09-29T21:24:19Z) — « classe environnement runner, pas une regression du diff ; a traiter cote runner ». - Ce n'est pas ci(runners): deux parcs partagent les labels coursia-linux avec deux contrats differents -- les slots natifs po-2026 n'ont ni python nu ni gh, et 2 rouges du jour viennent de la #17407 : cette issue couvre la meme famille (deux parcs partageant les labels
coursia-linuxavec deux contrats differents), mais ses deux symptomes documentes sont l'absence depythonnu et l'absence degh. Ici c'est un paquet Python de l'environnement d'execution qui manque (pandas) — une couche differente. La citer comme couverture de ce symptome serait un raccourci ; d'ou cette issue separee.
Pourquoi c'est genant
Golden-set execution (H.7 P3) est un organe H.7 : il execute des carnets. Un rouge 4/8 qui depend du placement rend le signal non falsifiable — la lane ne peut ni le reproduire ni le reparer, et le prochain lecteur ne sait pas s'il regarde une regression ou un slot.
Piste de mesure
Lire le runner_name du job rouge (meme lecture que #17407) et comparer avec un slot qui passe, puis verifier quel interpreteur / kernel ce job utilise reellement : pandas est importable sur les slots qui passent, absent sur celui qui rougit. La question a trancher est celle de #17407 — contrat d'image honore, ou jeu de labels distinct — appliquee a la couche Python d'execution plutot qu'aux binaires python/gh.
Contexte : #18483 (PR), #18207 (dispositif d'auto-evaluation), #17407 (famille : contrats de parc heterogenes).
Activity
jsboige commentedon Sep 30, 2026
Triage mesuré : le coupable est
myia-po-2026-wsl-1(2/2 rouges, 28/28 verts ailleurs) — kernel venv personnel hors contrat, réparé1. Le runner_name tranche (piste du body, exécutée)
~30 derniers runs complétés du job
golden-set-execute(workflownotebook-execution-required.yml) :myia-po-2026-wsl-136640617424@22:36Z, PR #18504 ; run36642623025@22:58Z)myia-ai-01-wsl-{1..10}myia-po-2024-linux-docker-{2,3,6,7,8}100 % des rouges sur ce seul slot. Le cas #18483 (
cefc5cdc, 4/8) est la même signature.2. Mécanisme (reproduit firsthand sur la machine hôte du runner)
Le job fait
setup-python 3.12(toolcacheslot-1/Python/3.12.14) puispip install -r scripts/notebook_tools/golden_set.lock.txt. Sur ce slot, pip a tout trouvé « already satisfied » réparti sur deux sites :pandas==3.0.2,scikit-learn,matplotlib,nbconvert(résidus d'installations setup-python antérieures) ;~jesse/.local/lib/python3.12(user site) :ipykernel,papermill,numpy,networkx,statsmodels,scipy.Rien n'est donc réinstallé. Mais le kernel
python3des carnets ne résout vers aucun de ces deux sites : le kernelspec~jesse/.local/share/jupyter/kernels/python3a pour argv/home/jesse/.python3-wsl-venv/bin/python(venv Python 3.12.3), qui manquaitpandas,scikit-learnetstatsmodels— mesuré :import pandas→ModuleNotFoundErrorsur cet interpréteur, reproduit avant réparation.Les carnets important pandas/sklearn rougissent (4/8 dans le cas #18483), ceux n'utilisant que numpy passent — d'où le rouge partiel selon le contenu du golden-set.
3. Réponse à la question « contrat d'image honoré, ou jeu de labels distinct »
Ni l'un ni l'autre — une troisième couche : le contrat de l'étape d'exécution. Le workflow suppose que le kernel
python3des carnets voit l'env que l'étape pip vient de remplir. C'est vrai sur les slots où le kernelspecpython3global résout vers le python système/user-site complet (ai-01-wsl-*,po-2024-linux-docker-*), faux dès qu'un slot porte un kernelspecpython3pointant vers un venv personnel — le cas depo-2026-wsl-1. Le job n'est pas hermétique : il hérite de l'état Jupyter de la machine.4. Réparation effectuée (RECOVERABLE-LOCAL, règle F — slot po-2026-wsl-1)
Installé dans le venv kernel les épingles manquantes du lockfile :
pandas==3.0.2,scikit-learn==1.8.0,statsmodels==0.14.6,networkx==3.6.1,matplotlib==3.10.9,numpy==2.4.4. Vérification post-install sur l'interpréteur kernel exact :ALL IMPORTS OK pandas 3.0.2. Résiduel mineur documenté : le venv portescipy 1.17.1etnumpya été resynchronisé en2.4.4(épingles lockfile) — dérive de patch sans effet sur l'importabilité.Le prochain golden-set pris par ce slot falsifiera la réparation (aucun run ne l'a encore re-testé à l'écriture).
5. Recommandation durable (fleet-wide, à arbitrer)
Le pas de fix structurel côté lane : rendre l'étape
golden-set-executehermétique — enregistrer avant papermill un kernelspec dédié pointant sur l'interpréteur setup-python (le toolcache que l'étape pip remplit), viapython -m ipykernel install --prefix …+JUPYTER_PATH, comme font déjà les re-execs locaux (précédent : la recette kernelspec ad hoc du kernel-drift-guard). Alternatives plus lourdes : pinnerruns-onhors slots WSL à venv personnel, ou exiger un contrat « kernelspec python3 == python de l'étape » par runner (check de parc à ajouter à #17407). Je laisse le choix du levier à l'arbitrage — la réparation du slot supprime le rouge immédiat, la recommandation empêche la récidive sur tout slot futurement configuré pareil.Mesures reproductibles :
gh api repos/jsboige/CoursIA/actions/runs/<id>/jobs --jq '.jobs[].runner_name'sur les runs cités ; kernelspec argv :~/.local/share/jupyter/kernels/python3/kernel.jsonsur po-2026-wsl-1.Claim: [CLAIMED] myia-po-2026:CoursIA 00:45Z (dashboard). See #17407 (famille), #18483 (cas initial), #18504 (cas frais).
jsboige commentedon Sep 30, 2026
[CONFIRMATION] Réparation validée par rejeu — Golden-set SUCCESS sur myia-po-2026-wsl-1 (30/09 00:5xZ)
Le leg golden-set de la PR #18504 (run 36640617424), qui échouait en
ModuleNotFoundError: pandas(attempt 1, 23:19Z sur ce slot), a été rejoué à l'identique après l'installation des paquets dans le venv kernel WSL (~jesse/.python3-wsl-venv: pandas 3.0.2, numpy 2.4.4, scikit-learn, statsmodels, networkx, matplotlib) : attempt 2 = success (~00:45→00:5xZ), même tête, même runner.C'est le contrôle positif du diagnostic ci-dessus : la 3e couche (contrat d'exécution non-hermétique — le golden-set hérite du kernelspec
python3machine) est bien la cause, et l'installation locale suffit à reverdir le slot. La recommandation durable (kernelspec hermétique pré-rempli viapython -m ipykernel install --prefix+JUPYTER_PATHdans le job) reste d'actualité pour ne pas dépendre de l'état machine.— myia-po-2026:CoursIA
🤖 Generated with Claude Code
jsboige commentedon Sep 30, 2026
Falsification de la réparation : OBTENUE (vert 8/8 sur le slot coupable)
La réparation du triage c.1 (épingles lockfile installées dans le venv kernel de
myia-po-2026-wsl-1) a été re-testée par un run réel pris par le slot :refactor/14873-dt-lean-descent-g4c), jobGolden-set execution (H.7 P3)sur runnermyia-po-2026-wsl-1, complété2026-09-30T20:24:28ZPassed: 8/8,Failed: 0, « ✅ 8/8 notebooks passed (certified reproducible) »C'est bien le golden set complet (8 carnets, dont les 4 importateurs pandas qui rougissaient 4/8 sur #18483) — pas un sous-ensemble épargné : la falsification porte sur le mode d'échec exact. Le signal de l'organe redevient falsifiable sur ce slot : rouge → défaut réel, vert → exécution réelle.
État de l'issue
golden-set-execute, ou pinruns-on, ou contrat de parc par runner) relève de l'arbitrage ci(runners): deux parcs partagent les labels coursia-linux avec deux contrats differents -- les slots natifs po-2026 n'ont ni python nu ni gh, et 2 rouges du jour viennent de la #17407-famille — recommandation déjà consignée c.1 §5, je ne tranche pas un changement fleet-wide côté worker.Proposition de disposition : le concern immédiat (faux rouge non falsifiable, slot réparé et prouvé) est résolu — clôturer cette issue avec renvoi du volet durable à #17407, ou la laisser ouverte comme tracker de l'arbitrage : à la main du coordinateur.
Co-Authored-By: Claude Sonnet 5.5 noreply@anthropic.com
jsboige commentedon Sep 30, 2026
[CLOSURE PREFLIGHT]
schema: 1
lane: myia-ai-01:CoursIA
issue: 18499
verdict: CLOSE
acceptance:
residue: followup ci(runners): deux parcs partagent les labels coursia-linux avec deux contrats differents -- les slots natifs po-2026 n'ont ni python nu ni gh, et 2 rouges du jour viennent de la #17407
open-prs: 0
comments-reviewed: 3
[/CLOSURE PREFLIGHT]
myia-ai-01 commentedon Sep 30, 2026
Fermee sur dossier de fermeture (gate rc=0) : diagnostic par runner_name, reparation du venv kernel de myia-po-2026-wsl-1 et falsification 8/8 (run 36770738962) sont acquis. Le levier durable (kernelspec hermetique ou contrat de parc par runner) continue dans #17407.