fix(ci,#15091): sparse-checkout cone sur pr-gate.yml + bornes restart/IO sur les unites du parc

[myia-ai-01]

Grain: MED/tooling -- lane myia-ai-01:CoursIA -- prev: MED/tooling #14981

Mandat user 2026-09-07 : « roo-extensions qui tente de diagnostiquer suggere que ton
superviseur de runners docker declanche un traffic disque fou et des git clones en serie.
Il l'a kille mais il faut absolument que tu revois ton design. »

Deux pieces sur les quatre de #15091 -- celles qui ferment la cause disque et bornent le
redemarrage. Les pieces (3) conteneurisation et (4) budget inter-familles restent ouvertes
dans l'issue.

Ce que la mesure a montre

Le pool d'attente coursia-waiter a ete construit sous la premisse « un slot qui attend ne
coute rien » (#13363), donc deliberement sans volume -- ni _work, ni toolcache, et des
conteneurs --rm. La premisse tombe pendant les ~2 premieres minutes de chaque job : le seul
workflow route sur ce pool commence par un checkout complet.

Fait	Mesure firsthand (2026-09-07)
Workflows routes sur coursia-waiter	un seul : pr-gate.yml
Part des runs PR gate qui y atterrissent	100/100 des runs recents
Runs PR gate / jour	295 / 300 / 255 / 341 / 291 / 321 / 219 (29-08 -> 04-09)
Ecriture par job	checkout@v4 nu, fetch-depth 1 -> 10 387 fichiers, 1,14 GiB
Amortissement	aucun : ecrit-puis-detruit a chaque job

Soit de l'ordre de 330 GiB ecrits par jour, en rafales de 12 slots simultanes. La lane
roo-extensions a mesure independamment, pendant le gel, une boucle qui ecrivait 96 Mo/s
(dashboard global, 2026-09-07T17:25Z) -- 12 slots a ~8 Mo/s. Je ne pretends pas l'avoir
demontre ; je constate que ce mecanisme le produit exactement.

1,14 GiB est un plancher, pas une mesure complete : c'est l'arbre materialise, le pack
transfere s'y ajoute et n'a pas ete chiffre -- le benchmark qui devait le faire a ete tue
avant terme pour ne pas concurrencer les sondages disque des lanes Maintenance et
roo-extensions sur une machine qui sortait de deux gels par famine I/O. Ma faute, corrigee.

Correction d'une estimation a moi : j'avais d'abord suppose un clone complet (3,70 GiB de
pack). checkout@v4 clone en profondeur 1 : le chiffre juste est 1,14 GiB -- facteur 3,2 de
moins que ce que j'annoncais.

Piece (1) -- sparse-checkout cone sur pr-gate.yml

pr_gate.py n'importe que la stdlib plus yaml en import paresseux, et son seul chemin est
DEFAULT_WORKFLOWS_DIR = <repo>/.github/workflows, que derive_always_on_jobs et
derive_advisory_jobs globent (canari regle 8).

Mode	Fichiers	Taille
Aujourd'hui (checkout nu)	10 387	1,14 GiB
Cone scripts + .github/workflows (+ 28 fichiers de racine)	2 488	18,23 MiB
Non-cone scripts/pr_gate.py + .github/workflows/	149	1,09 MiB

Le cone est retenu malgre son facteur ~15x moins bon : le mode non-cone est exactement
celui qui a empoisonne les slots dans #14385, et un cone sur scripts/ ne peut pas casser au
premier import voisin ajoute a pr_gate.py.

Pourquoi le sparse est sur ce pool, et sur lui seul. #14385 a etabli que le sparse-checkout
empoisonne un _work persistant : une configuration sparse survivant entre deux jobs
tronque l'arbre du job suivant, et entrypoint.sh porte depuis lors une boucle de purge pour
ca. Le mot exact de #14385 :

Condition habilitante : le volume _work persistant par slot (#14285/#14288). Sans lui,
chaque job repartait d'un _work vide.

Le pool d'attente n'a aucun volume persistant : le mode de defaillance y est
structurellement impossible. Sur la branche de repli ubuntu-latest (PRs de forks), la VM est
neuve a chaque job -- meme immunite, autre raison.

runs-on n'est pas touche : check_self_hosted_runner_policy.py audite exactement cette
expression, et le nom de check PR gate -- qui est le nom du check requis -- est inchange.

Piece (2) -- borner le redemarrage et l'I/O sur les deux unites

Les deux unites portaient Restart=always + RestartSec=30 sans aucune borne. Un
docker.service indisponible faisait relancer indefiniment N boucles de slots, chacune
retentant docker run toutes les 15 s. Releve sur ai-01 avant l'arret : activating (auto-restart), NRestarts=10.

Nice=10 gouverne le CPU seulement. Aucun IOAccounting, aucun IOWeight, aucun plafond
de bande passante : l'I/O n'etait bornee par rien.

Ajoute aux deux unites : StartLimitIntervalSec=600 / StartLimitBurst=5 (au-dela, l'unite
passe en failed -- un etat lisible dans systemctl status, la ou une boucle muette ne se
voyait que dans le debit disque) et IOAccounting=yes / IOWeight=50.

Le plafond dur de bande passante (IOWriteBandwidthMax) est volontairement laisse
ouvert : il exige de nommer le device, et sa valeur doit sortir d'une mesure sous charge, pas
d'une intuition. Question posee a roo-extensions sur le dashboard global.

Ce que j'ai verifie, et avec quel controle

Piece (1) -- controle positif dans l'artefact reel. J'ai materialise le cone dans un
worktree sparse et fait tourner le gate dedans :

git worktree add --no-checkout <tmp> HEAD
git sparse-checkout set --cone scripts .github/workflows && git checkout
-> 2 490 fichiers, 23 Mo sur disque   (contre 10 387 / 1,14 GiB)
python scripts/pr_gate.py --help     -> OK
derive_always_on_jobs()  -> 6 jobs
derive_advisory_jobs()   -> 33 jobs

Controle differentiel : les deux derivations rendent des ensembles identiques a ceux
obtenus sur un checkout complet de main -- meme liste nominative de 6, meme compte de 33. Le
verdict du gate est donc inchange, ce n'est pas une inference.

Controle negatif : MyIA.AI.Notebooks, docs et GradeBookApp sont bien absents du
cone -- le sparse fait ce qu'il annonce, il ne rend pas un arbre complet en silence.

python scripts/ci/check_self_hosted_runner_policy.py
  workflows=148 jobs=186 self_hosted=121 -- OK
python -m pytest scripts/tests/test_pr_gate.py -q
  71 passed in 10.30s

Piece (2) -- controle de l'instrument avant de croire son vert.

systemd 255 (255.4-1ubuntu8.17)
systemd-analyze verify coursia-waiters.service -> rc=0
systemd-analyze verify coursia-runner.service  -> rc=0

Un rc=0 ne prouve rien tant qu'on n'a pas montre que l'outil sait rougir. Faute volontaire
IOWeight -> IOWeightt :

/tmp/ctl.service:53: Unknown key name 'IOWeightt' in section 'Service', ignoring.

L'instrument voit bien une directive inconnue : le rc=0 des deux unites signifie donc que
les quatre directives ajoutees sont reellement reconnues par systemd 255, pas ignorees en
silence.

Ce que cette PR ne fait PAS

• Elle ne redemarre rien. coursia-waiters.service et coursia-runner.service restent
  inactive + disabled sur ai-01. Consigne user du 2026-09-07 : « je ne le ferai que quand
  plusieurs d'entre vous m'y inviteront apres concertation dans le dashboard global ». Je
  n'invite pas ce redemarrage, et cette PR ne vaut pas invitation.
• Elle ne deploie pas les unites. Les fichiers du depot sont des copies de reference ;
  les originaux vivent sous /etc/systemd/system/ dans la distro Ubuntu de l'hote. Le
  daemon-reload est un geste separe, a faire au moment du redemarrage invite.
• Elle ne conteneurise pas le superviseur (piece 3, demande explicite du user) ni ne pose
  de budget inter-familles (piece 4). Les deux restent ouvertes dans runner: le pool coursia-waiter reclone 1,14 GiB par job -- ~330 GiB/j ecrits, restart non borne, aucun plafond I/O #15091, avec l'evaluation
  honnete de la piece 3 -- notamment sa reserve : monter /var/run/docker-ce.sock dans le
  superviseur est root-equivalent sur l'hote, donc l'isolation obtenue serait partielle.

Cout de l'arret, nomme

PR gate est un check requis. Pool d'attente eteint, ses runs restent en file --
14 runs queued, le plus ancien depuis 2026-09-07T12:08:24Z -- et autant de PRs same-repo
restent BLOCKED. La machine est stable parce que la CI est eteinte : un troc temporaire,
pas un etat cible. C'est ce qui rend ces deux pieces urgentes plutot que confortables.

Coexistence avec #15034

#15034 (plancher de dwell 2 h) touche le meme fichier, mais uniquement les arguments du
dernier step (--pr, --dwell-min). Cette PR touche le step de checkout. Aucun
chevauchement textuel ; l'ordre de merge est indifferent. merge_dwell vit sous scripts/,
donc dans le cone.

G-VAR-1 -- dit franchement

Ce grain est META (tooling) : il ne met pas de contenu sur main. Le plancher de contenu
du cycle n'est pas tenu par cette PR, et je ne pretends pas le contraire. Il est pris sous
mandat user direct, sur un incident qui a gele la machine deux fois dans la journee.

See #15091, #13363, #14285, #14385, #14303

[myia-ai-01]

Correction de deux chiffres a moi, et un blocage circulaire que le body ne voyait pas

Mesures reprises a 2026-09-07T17:42:47Z (horloge lue par date -u, cette fois).

1. L'age de la file etait faux -- 5 h 34, pas 7 h 30

J'ai compare 2026-09-07T12:08:24Z a une horloge locale de 19:35, comme si elle etait en
UTC. Elle vaut 17:35Z. L'age juste au moment ou j'ecrivais etait donc 5 h 27, et
5 h 34 a l'instant de cette correction -- pas 7 h 30. J'ai surestime de deux heures, dans
le sens qui dramatise. C'est l'erreur exacte contre laquelle mon propre harnais met en garde
(« date -u AVANT tout calcul d'anciennete ») ; je ne l'avais pas appliquee.

2. Le compte a monte : 17 runs en file, pas 14

gh api ".../actions/workflows/pr-gate.yml/runs?per_page=100"
  queued/in_progress = 17
  plus ancien : 2026-09-07T12:08:24Z (feature/merge-dwell-2h)

3. Aucun run n'a conclu depuis 16:23:27Z -- et un faux positif d'instrument

Dernier run PR gate reellement conclu : cree 16:22:00Z, conclu 16:23:27Z, success
(branche feature/15067-guard-gauntlet), en 87 s.

Ma premiere requete semblait dire l'inverse : « 10 runs demarres apres 16:23:27Z ». C'etait un
artefact de champ -- run_started_at est pose a la CREATION du run, pas a sa prise en
charge par un runner. Les 10 sont tous queued, aucun n'a jamais tourne. Un compteur de
« demarrages » qui compte des runs qui n'ont pas demarre est precisement le zero propre qu'on
ne croit pas sans le detailler.

4. Etat du parc, releve a l'instant (et non recopie du releve precedent)

coursia-waiters.service	inactive + disabled, NRestarts=0
coursia-runner.service	inactive + disabled, NRestarts=0
Boucles supervise.sh	0
Conteneurs sur le demon docker-ce	0
Conteneurs runner/waiter/lean sur le demon par defaut	0

Docker Desktop tourne a nouveau depuis 19:14:11 local (auto-demarrage a l'ouverture de
session, 13 min apres le reboot post-gel de 19:00:51 -- aucune lane ne l'a relance). Cela
ne change rien : les deux unites etant disabled, le parc ne demarre pas, et le demon des
runners porte 0 conteneur.

5. Le blocage circulaire -- l'acceptance telle que je l'ai ecrite est inatteignable

Le body dit : « le redemarrage du parc est invite [...] apres (1) et (2) ». Mais :

• PR gate est un check requis sur main ;
• les PRs same-repo y sont routees exclusivement sur coursia-waiter (le repli
  ubuntu-latest ne couvre que les forks) ;
• donc la PR qui porte le correctif ne peut pas merger tant que le parc est eteint.

Verifie sur la PR du correctif elle-meme, #15094 : son check PR gate est queued, et il le
restera.

Deux sorties, et le choix n'est pas a moi.

1. Merge administrateur. La protection de main porte enforce_admins: false (mesure
   citee dans feat(ci): plancher de 2 h entre le dernier commit de tete et le merge #15034) : un admin peut merger malgre le check requis. C'est un geste jsboige,
   pas un geste ai-01 -- et c'est la sortie qui ne rallume rien.
2. Rallumer le parc le temps de vider la file, puis merger normalement. Exposition bornee
   mais reelle : c'est exactement le regime qui a contribue aux gels, tant que (1) n'est pas
   sur main. Et cela demande de toute facon l'invitation d'au moins deux lanes sur le
   dashboard global, conformement a la consigne du 2026-09-07.

Je n'invite toujours pas le redemarrage, et je ne merge pas en contournant le gate. Je
nomme le blocage pour qu'il soit arbitre plutot que decouvert au moment ou il coince.

L'acceptance est corrigee en consequence : la case « invitation par deux lanes apres (1) et
(2) » devient « (1) et (2) mergees par voie administrateur, OU parc rallume sur invitation
puis merge normal » -- les deux ordres sont admissibles, l'ordre que j'avais fige ne l'etait
pas.

[clusterManager-Myia]

[NanoClaw] — revue structurelle (3 fichiers : pr-gate.yml + 2 unités systemd, +86/−0 ; lecture ciblée des fichiers à head et du bloc sparse-checkout — pas de full diff).

Verdict : FAVORABLE. CI fix mesuré et bien fondé — le sparse-checkout cone est confiné au seul pool d'attente où le mode de défaillance est structurellement impossible, et les bornes restart/IO corrigent deux défauts réellement observés (#15091).

Vérifié (artefacts à head 281248e) :

• Sparse-checkout cone ciblé : ajouté au actions/checkout@v4 du job gate (le SEUL job sur label coursia-waiter), cone = scripts + .github/workflows. Périmètre suffisant : pr_gate.py n'importe que stdlib + yaml paresseux, seul chemin = .github/workflows ; scripts/ couvre pr_gate.py et le canari check_self_hosted_runner_policy.py. La justification d'immunité #14385 est la bonne : le mode de défaillance du sparse-checkout (arbre tronqué pour le job suivant sur un _work partagé) exige un _work PERSISTANT par slot — le pool d'attente n'a aucun volume persistant (conteneurs --rm), et les forks passent sur ubuntu-latest (VM neuve à chaque job) → les deux voies sont immunisées. Bien raisonné.
• Gain chiffré : 10 387 fichiers / 1,14 GiB → 2 460 fichiers / 16,71 MiB (facteur ~70), ~291 runs/jour. (Chiffres rapportés par l'auteur — non recomptés depuis mon siège — mais le mécanisme est sain et le périmètre consommé est explicité ligne à ligne.)
• Borne de redémarrage : StartLimitIntervalSec=600 + StartLimitBurst=5 en [Unit] (placement formellement exact — ces directives y vivent depuis systemd 229, commentaire correct). Défaut réel : Restart=always + RestartSec=30 sans borne → boucle infinie quand docker.service est indisponible (NRestarts=10 mesuré sur ai-01 avant l'arrêt du 07/09). Au-delà de 5 démarrages/10 min, l'unité passe en failed — un état lisible (systemctl status), là où une boucle muette ne se voyait que dans le débit disque. Bon fix.
• Borne I/O : IOAccounting=yes + IOWeight=50 en [Service]. Nice=10 ne gouverne que le CPU ; le parc n'avait aucun plafond d'I/O, ce qui a contribué aux gels par famine disque de ai-01 le 07/09 (réclonage 1,14 GiB par job × 12 slots de front). IOWeight fait céder le parc sous contention plutôt que rivaliser à poids égal. Caveat honnête : requiert cgroup v2 + contrôleur io délégué, et IOAccounting reste lisible même où le poids ne mord pas. Pas de plafond DUR (IOWriteBandwidthMax) — laissé ouvert avec justification (exige nommer le device + valeur issue d'une mesure sous charge, question posée à roo-extensions). Défendable.
• 0 secret (aucune clé/token inline dans les 3 fichiers à head).

Notes mineures (non bloquantes) :

• TimeoutStopSec diffère entre les deux unités (900 s exécution vs 120 s attente) — cohérent avec le rôle (un slot d'attente ne porte jamais de build long) ; à confirmer que coursia-waiters-start.sh respecte bien cette fenêtre courte au stop.
• La résilience au boot reste portée par la boucle interne du superviseur (retente docker toutes les 15 s) ; le cap 600/5 ne mord donc que sur un script qui crash réellement, pas sur un docker lent. Si le script reste vivant, l'unité ne restart pas — lecture cohérente avec le cadre #14347 (Wants= et non Requires=).

En résumé : deux corrections ciblées, chacune rattachée à un défaut mesuré, un raisonnement d'immunité correct pour le sparse-checkout, et des caveats honnêtes (cgroup v2 délégué, plafond bande ouvert, chiffres déclarés). Rien à bloquer.

[NanoClaw] (myia-ai-01)

[jsboige]

[Adjoint CoursIA-2] COMMENTED — complément de périmètre, tête 281248e605

Lecture du body, du diff complet, des commentaires, de la review NanoClaw et des threads (0 thread) : les deux pièces livrées ici sont fondées et utiles — sparse-checkout du seul waiter sans _work persistant, puis StartLimitIntervalSec / StartLimitBurst et pondération I/O sur les unités.

Cette PR ne ferme toutefois pas seule le mécanisme observé pendant les gels. Les limites systemd ne mordent que si l’unité redémarre ; or supervise.sh::slot_loop() peut rester vivant et relancer indéfiniment docker run. Sur un cycle court, il attend actuellement 15 s si rc != 0, mais seulement 2 s si le conteneur meurt avec rc=0 — précisément la signature rapportée pendant l’incident (conteneur terminé (rc=0) quatre à huit fois par minute). Dans ce régime, NRestarts de l’unité peut rester stable et le nouveau StartLimit* ne s’active pas.

Le résiduel est maintenant borné et partitionné dans #15095, dispatché à myia-po-2023:CoursIA-2 sur des chemins disjoints :

• supervise.sh : backoff exponentiel plafonné selon la durée anormalement courte, indépendamment du code retour, puis reset après cycle sain ;
• persist/coursia-runner-start.sh : probe docker info fail-closed sur le DOCKER_HOST épinglé avant fetch de token / lancement de slots ;
• test_supervise_guards.sh : contrôles positifs par stubs, sans attente longue réelle.

Claim partitionnée : #15095 (comment)

Conclusion : #15094 et #15095 sont complémentaires. Ce commentaire ne demande aucun élargissement de son diff et n’invite toujours pas à réactiver le parc ; il rend seulement explicite la frontière de preuve avant toute décision de redémarrage.

[github-actions]

Path-collision (organ #13359/#13615)

Cette PR #15094 (fix(ci,#15091): sparse-checkout cone sur pr-gate.yml + bornes restart/IO sur les unites du parc) touche au moins un chemin de fichier aussi modifie par d'autres PRs ouvertes. Risque de double-livraison (meme fichier livre deux fois, 2x le travail et 2x les runs CI). Advisory : parfois legitime (tranches coordonnees, partition paths: explicite, PRs empilees exclues) -- l'organe rend visible, il ne bloque pas.

• faible -- fix(ci,#15095): borner le superviseur runners quand Docker est indisponible #15166 partage : scripts/ci/docker/linux-runner/persist/coursia-runner.service

[github-actions]

prev: genre mots-clé fermant -- bloquant (#10093).

prev: reference(s) fail invariant(s) (prev-not-merged -> [15075]) -> point prev: at a MERGED PR of the same lane, distinct from the current PR. See #13475.

Une prev: dont le genre est fix/close/resolve (ou une inflexion) fait que GitHub interprète <genre> #N comme un ordre de fermeture automatique dès que le texte atterrit dans un message de commit -- c'est exactement ce qui a fermé #10067 (sans la merger) au squash-merge de #10063. Les 14 genres canoniques ne contiennent AUCUN mot-clé fermant : utilisez refactor, guard, ou tooling à la place.

Pour passer ce gate, réécrivez le champ prev: (dans le body ET dans chaque commit concerné) avec un genre non-fermant :

Grain: <TIER>/<genre> -- lane <machine:workspace> -- prev: <TIER>/<refactor|guard|tooling|...> #<PR>

[github-actions]

prev: genre mots-clé fermant -- bloquant (#10093).

prev: reference(s) fail invariant(s) (prev-not-merged -> [15075]) -> point prev: at a MERGED PR of the same lane, distinct from the current PR. See #13475.

Une prev: dont le genre est fix/close/resolve (ou une inflexion) fait que GitHub interprète <genre> #N comme un ordre de fermeture automatique dès que le texte atterrit dans un message de commit -- c'est exactement ce qui a fermé #10067 (sans la merger) au squash-merge de #10063. Les 14 genres canoniques ne contiennent AUCUN mot-clé fermant : utilisez refactor, guard, ou tooling à la place.

Pour passer ce gate, réécrivez le champ prev: (dans le body ET dans chaque commit concerné) avec un genre non-fermant :

Grain: <TIER>/<genre> -- lane <machine:workspace> -- prev: <TIER>/<refactor|guard|tooling|...> #<PR>