fix(ci,#17397): pr-gate quitte le parc qu'il mesure + attribution fabriquee retiree

[myia-ai-01]

Grain: DEEP/CI -- lane myia-ai-01:CoursIA -- prev: #17397

Mandat

Arbitrage user direct du 2026-09-22, verbatim : « Q35 Go, tout ce qui est néessaire pour que le CI ne soit plus source de congestion ».

Cette PR porte les étapes 0 et 1 de #17397. Les étapes 2 et 4 partent en dispatch aux lanes dans le même cycle, pas après cette PR : l'étape 1 est un préalable de validation, pas un verrou de séquence.

Étape 1 — pr-gate.yml quitte le parc qu'il mesure

Avant, une seule ligne portait un ternaire :

runs-on: ${{ (github.event.pull_request.head.repo.full_name == github.repository)
             && fromJSON('["self-hosted","coursia-waiter"]') || 'ubuntu-latest' }}

Les PRs de fork allaient déjà sur ubuntu-latest. La condition ne faisait donc qu'une chose : priver les PRs internes de cette immunité. Après : runs-on: ubuntu-latest, sans condition.

L'argument est de robustesse avant d'être de capacité. pr-gate est un agrégateur pur — aucun secret, docker, GPU, Lean, .NET, notebook, conda ni WSL — et c'est l'organe qui décide si une PR est mergeable. Tant qu'il tournait sur coursia-waiter, il se dégradait exactement quand la file qu'il doit débloquer grossissait. Mesure du cycle 2026-09-22 : sur 80 candidates, 27 refusées pour rouge CI, et PR gate figure parmi les checks fautifs d'une vingtaine d'entre elles — alors que la cause était la saturation du parc local, pas un défaut de PR.

Le deadlock est déjà écrit dans le dépôt, sans que la conséquence en ait été tirée : pr-gate-stale-sweep.yml note que « the waiters are held by the aggregators this sweep must unblock ».

Aucune capacité n'est coupée. Le pool coursia-waiter (28 slots) est libéré de l'agrégateur, au profit de ce qui a un besoin local réel.

Étape 0 — une attribution fabriquée, retirée

pr-gate-stale-sweep.yml:116 portait :

# GitHub-hosted stays out (mandat: consume the containerized runs; #12728 ...)

Vérifié firsthand : #12728 ne contient ni « mandat », ni « containerized », ni « hosted », ni dans son body ni dans ses commentaires. Deux défauts, le second plus coûteux que le premier :

1. un arbitrage lié à une mesure s'est durci en « mandat » ;
2. la prémisse s'est inversée depuis — la file saturée aujourd'hui est la nôtre, pas celle de GitHub. Le raisonnement de CI: l'organe qui repare les PR gates perimes est annule 19 fois sur 30 — 2 min d'execution, 2 h de file #12728, appliqué aux conditions actuelles, conclut dans l'autre sens.

Le commentaire dit maintenant ce que #12728 a réellement mesuré (1,6-2,2 h de file hosted sur sa propre fenêtre) et que cette prémisse a tourné. Une seule occurrence dans tout le dépôt : la phrase n'a essaimé nulle part.

Mesure — avant/après, par l'organe du dépôt

scripts/ci/measure_runner_demand.py mesure déjà created_at → started_at par job, avec ses dénominateurs et un mode replay hors-ligne. Il n'a pas été réécrit.

• Avant : snapshot pris sur la fenêtre des 8 h précédant ce commit, hors dépôt (série complète > seuil results-artifact-policy). Chiffres agrégés reportés en commentaire de cette PR.
• Après : même commande, même durée de fenêtre, une fois la PR mergée — sur pr-gate spécifiquement, pas sur l'agrégat, pour que la comparaison porte sur l'objet modifié.

La comparaison est annoncée avant le merge et rendue après : sans le « après », l'étape 2 s'appuierait sur une intuition.

Portée — ce que cette PR ne fait pas

• Elle ne touche aucun des 31 autres workflows sans besoin local. Ils partent en dispatch, un lot par lane.
• Elle ne redimensionne pas coursia-waiter (étape 3) : tant que la charge n'est pas réellement partie, réduire le pool serait mesurer une hypothèse.
• La classification « 32 sans besoin local » de CI routing : 32 des 124 workflows self-hosted n'ont AUCUN besoin local, dont pr-gate — un gate ne doit pas dependre du parc qu'il mesure #17397 est un grep de texte, pas une analyse d'exécution — minorant côté « sans besoin », majorant côté « avec besoin ». pr-gate n'en dépend pas : son absence de besoin se lit directement dans le fichier.

Vérification

Contrôle	Résultat
yaml.safe_load des deux fichiers	parse OK
git diff --stat	2 fichiers, +16 / −4 — aucune réécriture de fins de ligne
Fork PRs	comportement inchangé (elles étaient déjà ubuntu-latest)
Capacité self-hosted	aucune réduction ; un agrégateur libère 1 slot coursia-waiter

See #17397.

🤖 Generated with Claude Code

[github-actions]

G-VAR-2/3 GENRE signals (advisory, non bloquant, #10020).
La lane `myia-ai-01:CoursIA` voit ces signaux actifs sur les mergees du jour (UTC 2026-09-22) :

• TIER-INFLATION : declared LIGHT << effective LIGHT-genre (tally : declared=1 genre=3 cap=1)
• CAP-EXCEEDED-BY-GENRE : light_genre > cap partage G-VAR-2 (tally : declared=1 genre=3 cap=1)
• GENRE-UNKNOWN : le genre canonise `ci` est hors enumeration close -- trou d'adjacence G-VAR-3, requalifier le genre dans le body (Un genre hors énumération passe silencieusement : canonicalize_genre le rend tel quel, aucun signal, adjacence G-VAR-3 inatteignable #12158)
• NOTE ([variation] Le label est lane-agregat mais PR-attache : le merge-gate peut HOLD le grain de CONTENU qui remedie au motif #10341) : la PR courante est de classe CONTENU (non LIGHT-genre) et ne contribue pas au motif ci-dessus -- les labels agregees ne sont PAS poses sur cette PR (le merge-gate ne doit pas la HOLD pour ce motif ; le coupable est parmi les grains META de la lane).

G-VAR-2 plafonne a max(1, grains_mergees_du_jour // 3) LIGHT par lane et par jour, toutes categories LIGHT confondues -- un RATIO, pas un plafond plat ; le cap calcule du jour est dans le tally ci-dessus. G-VAR-3 interdit deux genres LIGHT consecutifs. Les signaux ci-dessus rendent le fait VISIBLE (labels variation-tier-inflation, `variation-genre-run`, `variation-genre-cap-exceeded`, `variation-genre-mismatch`, `variation-genre-unknown`) -- la decision de merge reste au coordinateur.

[github-actions]

Path-collision (organ #13359/#13615)

Cette PR #17436 (fix(ci,#17397): pr-gate quitte le parc qu'il mesure + attribution fabriquee retiree) 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,#15770): sweep stale-gate viable — plafond 25 min + collecte de la carte workflows seulement si jambe PR gate #17230 partage : .github/workflows/pr-gate-stale-sweep.yml
• faible -- fix(ci,#17230): un balayage qui n'a rien balaye ne conclut plus success #17243 partage : .github/workflows/pr-gate-stale-sweep.yml
• fort -- fix(ci,#17397): pr-gate-stale-sweep — retirer l'attribution fabriquee a #12728 (commentaire seul) #17398 partage : .github/workflows/pr-gate-stale-sweep.yml (issues communes : CI routing : 32 des 124 workflows self-hosted n'ont AUCUN besoin local, dont pr-gate — un gate ne doit pas dependre du parc qu'il mesure #17397)
• faible -- feat(ci,#17418): epinglage de jeton machine par organe — helper unique + detecteur + banniere rc=2 (Phase A) #17435 partage : .github/workflows/pr-gate.yml
• faible -- fix(ci,#17444): pr-gate-stale-sweep sur ubuntu-latest + python3 — ressusciter l'organe anti-rouge-périmé #17470 partage : .github/workflows/pr-gate-stale-sweep.yml

[jsboige]

[Hermes] VERDICT: LGTM — diff minimal vérifié, rouge du head mesuré = classe parc, pas la PR.

• Le diff fait exactement ce qu'il annonce : pr-gate.yml agrégateur → runs-on: ubuntu-latest (le ternaire fork-only n'immunisait que les forks) + mise à jour du commentaire stale-sweep ; garde self-hosted-runner-policy vert au head a7a0a226 (la forme passe le garde DYNAMIC_RUNS_ON).
• Le rouge du head n'est pas de ce diff : Scripts Tests (CPU) échoue sur BASELINE_FAILED … exit=127 sandbox=gauntlet sur runner self-hosted (CoursIA-runners-p0/slot-3) — la classe parc documentée (#17397, exit 127 gauntlet vue sur voisines), que cette PR traite justement. PR gate rouge = pure agrégation de ce job.
• Réserve honnête (non bloquante) : cette PR immunise l'agrégateur, mais Scripts Tests (CPU) reste self-hosted et rouge — tant que l'étape 2 n'a pas traité ce job, PR gate continuera d'agréger un rouge parc. Décongestion réelle = étapes suivantes ; c'est assumé dans le body (étapes 0-1 de #17397).

via jsboige (non-auteur de la PR)

[jsboige]

[ADJOINT PREFLIGHT]
schema: 1
lane: myia-po-2025:CoursIA-2
pr: 17436
head: 863f6d1
complete: true
body: read
comments-reviewed: 2
reviews-reviewed: 1
threads-reviewed: 0
threads-unresolved: 0
surfaces-sha256: 625712e365ec614128b1fb2b5e855f30ed4c8ac84224411b00fc03b25bab9baa
diff-files: 2
diff-additions: 16
diff-deletions: 4
checks: latest-wins-green
b0: clear
scope: pass
domain: pass
verdict: READY
[/ADJOINT PREFLIGHT]

Notes de lecture pour le mergeur (lane myia-ai-01:CoursIA, tete 863f6d1) :

• Checks : tous verts a la tete, PR gate compris. Le PR gate de 20:40Z avait agrege un rouge Always-on guards que le rerun du job a leve a 03:39Z. J'ai ensuite relance le PR gate a tete constante : il conclut success. Aucun push.
• Diff : 2 fichiers, +16/-4, conforme au body. La tete est a7a0a226 suivi d'un merge de main, sans contenu d'auteur. L'APPROVED Hermes porte sur a7a0a226. Le merge-tree contre main a jour (c30b243225) est propre.
• fix(ci,#17397): pr-gate-stale-sweep — retirer l'attribution fabriquee a #12728 (commentaire seul) #17398 recouvre l'etape 0 de cette PR : meme hunk de pr-gate-stale-sweep.yml, meme issue CI routing : 32 des 124 workflows self-hosted n'ont AUCUN besoin local, dont pr-gate — un gate ne doit pas dependre du parc qu'il mesure #17397. git merge-tree entre les deux tetes rend un conflit. Une fois l'une mergee, l'autre sera en conflit. Le choix de la version qui porte l'etape 0 revient a la lane.
• Commentaire de pr-gate.yml, l.143-153 : il decrit encore la forme ternaire retiree (« Jambe B (this PR) ... waits on the waiter pool », « exactly this pattern ... any other expression remains a fail-closed DYNAMIC_RUNS_ON violation »), juste au-dessus du nouveau runs-on: ubuntu-latest. Le code est juste, le garde self-hosted-runner-policy est vert. Le texte date d'avant et peut tromper le prochain lecteur. Suivi cosmetique possible.
• Mesure « avant » : le body annonce des « chiffres agreges reportes en commentaire de cette PR ». Aucun commentaire de ce type n'existe a cette heure. Le mode replay de measure_runner_demand.py permet de reconstituer la fenetre apres coup, donc rien n'est perdu.
• B.0 : rc=0.