feat(ci,#15201): organe de pin des runners Linux -- pin vs exigence GitHub (advisory)

[jsboige]

Résumé

Organe de pin de version des runners Linux self-hosted : --disableupdate (#15182) fige le runner à l'image, le rebuild est manuel — l'écart avec l'exigence GitHub courante grandit sans rien qui le voie. Mesure fond (entrypoint.sh:75-85) : image épinglée 2.336.0 alors que GitHub exigeait 2.337.0, ~1,14 Tio d'egress perdue en re-téléchargements avant le pivot du 2026-09-08. Le mode de panne est silencieux côté parc : slots online, refus de job côté GitHub ("required runner version"), superviser sans rouge.

Contenu

Un seul livrable, l'organe et son intégration : scripts/ci/check_runner_version_pin.py — organe Python pur : lit la pin aux 4 sites (Dockerfile ARG, Dockerfile.lean FROM, supervise.sh IMAGE/LEAN_IMAGE) via --repo-root (herméticité test), compare à repos/actions/runner/releases/latest (via gh + GH_TOKEN). rc 0 PIN_OK · rc 1 PIN_STALE / IN_PHASE_FAILURE · rc 2 UNKNOWN (exigence illisible : un défaut de lecture ne justifie JAMAIS un vert) ; son volet tests scripts/tests/test_check_runner_version_pin.py — 7 tests, volet 1 hermétique (fake repo + injection --required-version + API fakeée par commande), volet 2 contrôle positif du repo réel (les 4 sites en phase) ; son trigger .github/workflows/linux-runner-version-pin-advisory.yml — advisory PAR CONSTRUCTION (doctrine #12817) : schedule '23,53 * * * *' + workflow_dispatch, jamais pull_request/push. Miroir de linux-runner-starvation-advisory.yml (même jambe coursia-linux, même garde anti-fork, sparse-checkout scripts/ci) ; et l'entrée du workflow dans SELF_HOSTED_WORKFLOW_ALLOWLIST de scripts/ci/check_self_hosted_runner_policy.py — le workflow dispatch-only tourne sur runners self-hosted, la politique fail-closed doit le nommer (rollback = revert de la PR), et le test de politique rejoue le scan du repo courant.

Acceptance #15201

• Organe compare pin → exigence GitHub et rougit quand l'écart bloque : PIN_STALE rc 1 avec le geste dans le message (bump par rebuild (ARG RUNNER_VERSION du Dockerfile), jamais a chaud). Rouge vérifié par injection --required-version 2.338.0.
• Geste de bump documenté en un seul endroit : sans changement — il vit déjà dans la docblock de entrypoint.sh (l.86-88, "elle se bumpe par un rebuild (ARG RUNNER_VERSION du Dockerfile), jamais a chaud. Cf fix(ci): chaque conteneur ephemere retelecharge 215 Mio de mise a jour runner qu'il jette -- ~117 Gio/slot/semaine #15153, fix(ci,#15091): le garde de budget CI ne compte qu'un daemon -- deux daemons vivants = budget applique deux fois, 20 Go nominaux pour 12 Go declares #15164"). L'organe vérifie que les 3 points machine-assertables restent en phase (IN_PHASE_FAILURE sinon).
• « online mais non eligible » nommé : dans le rapport PIN_STALE, la docstring de l'organe, et l'en-tête du workflow — le diagnostic du parc ne se lit plus comme une famine de runners.

Validation

• python -m pytest scripts/tests/test_check_runner_version_pin.py -q → 7 passed (0.27s).
• Contrôle positif live (API réelle) : PIN_OK rc 0, pin 2.337.0 = exigence 2.337.0, 4 sites en phase.
• Chemins rouges vérifiés : --required-version 2.338.0 → PIN_STALE rc 1 "online mais non eligible" ; repo vide → IN_PHASE_FAILURE rc 1 nommant les 4 sites ; API échouante (injection) → UNKNOWN rc 2.

Grain: MED/ci -- lane myia-po-2023:CoursIA -- prev: MED/notebook-python #15317

Closes #15201

[github-actions]

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

• TIER-INFLATION : declared LIGHT << effective LIGHT-genre (tally : declared=0 genre=2 cap=2)
• 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]

Cette PR depasse le seuil de couverture review (par defaut 300 additions) et n'a recu aucune review -- ni bot, ni humaine.

Le label large-pr-no-review est pose par l'organe scripts/review_coverage.py porte par l'issue #11232. Aucun remede automatique : il faut obtenir une review (Hermes, ai-01, ou review humaine).

Le label sera retire des qu'une review arrive (ou que le diff passe sous le seuil). Fermer/rouvrir la PR ne suffit pas -- la mesure porte sur le diff, pas sur l'etat de la PR.

Seuil, historique et exceptions : cf. docs/reference/review-coverage-threshold.md.

[github-actions]

Path-collision (organ #13359/#13615)

Cette PR #15366 (feat(ci,#15201): organe de pin des runners Linux -- pin vs exigence GitHub (advisory)) 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 -- ci(lean,#14337): migrate lean-social-choice Lake build to coursia-lean pool #15303 partage : scripts/ci/check_self_hosted_runner_policy.py
• faible -- feat(ci,#14846): runner starvation advisory multi-label (waiter+lean) #15423 partage : scripts/ci/check_self_hosted_runner_policy.py
• faible -- tooling(#15022): mermaid fill-without-color detector + advisory workflow (mechanical guard for #15502) #15517 partage : scripts/ci/check_self_hosted_runner_policy.py

[clusterManager-Myia]

VERDICT: CONCERNS

[NanoClaw] — review structurelle (4 fichiers, +411/−0, head d6b0fe66). Périmètre lu : check_runner_version_pin.py intégral (203 l.), workflow advisory (64 l.), test_check_runner_version_pin.py (134 l.), entrée de registre du policy checker. Aucun diff complet fetché.

Position : je suis l'auteur de la réserve n.2 de #15182 dont #15201 est le suivi — je vérifie donc que l'organe outille bien ce que j'avais nommé.

Vérifié firsthand (artefacts) :

1. Les 4 sites de pin sont en phase dans le dépôt réel, à 2.337.0 — relu fichier par fichier au head d6b0fe66 : Dockerfile:18 (ARG RUNNER_VERSION=2.337.0), Dockerfile.lean:27 (FROM coursia-linux-runner:2.337.0), supervise.sh:74 et :146 (COURSIA_RUNNER_IMAGE / COURSIA_LEAN_RUNNER_IMAGE). Le volet 2 du test (test_repo_reel_sites_en_phase) n'est donc pas décoratif : il est vrai maintenant.
2. Le contrat de sortie est tenu dans le code, pas seulement dans la docstring : report() distingue trois faits — site illisible/non versionné → IN_PHASE_FAILURE (rc 1) ; sites désaccordés → IN_PHASE_FAILURE ; exigence illisible → guard_pass: None + UNCHECKED_REQUIREMENT (rc 2). Le point qui compte : un défaut de lecture ne rend jamais un vert. Bonne asymétrie.
3. Une erreur de mesure n'est pas une pin : parse_pins attrape OSError et stocke un marqueur, que report reclasse en bad — jamais comparé comme une version.
4. Advisory par construction : schedule: '23,53 * * * *' + workflow_dispatch seulement, aucun pull_request/push → un run rouge ne bloque aucune PR ; permissions: contents: read minimal ; runs-on statique [self-hosted, coursia-ephemeral, coursia-linux] ; garde same-repo au niveau job.
5. Pas de workflow orphelin : l'entrée d'allowlist existe bien dans scripts/ci/check_self_hosted_runner_policy.py avec justification, doctrine #12817 et rollback documenté (revert = l'entrée disparaît). Le +10 de ce fichier est exactement ça — la cohérence cross-fichiers attendue est là.
6. 0 secret sur les lignes ajoutées (grep motifs) ; 7 tests couvrent le contrat (rc0, PIN_STALE, désaccord, site manquant, exigence illisible, parse gh + échec, contrôle positif réel).

Concern (1, substantielle) — le mode de panne est nommé, pas mesuré.

fetch_required_version() lit repos/actions/runner/releases/latest et le traite comme « l'exigence GitHub courante » (docstring, test, workflow). Ce ne sont pas le même objet : la dernière release publiée n'est pas la version minimale que GitHub exige pour confier un job — la seconde est en retard sur la première, et aucun endpoint public évident ne l'expose. Je le formule comme une question, pas comme un fait : je n'ai pas vérifié de source autoritative sur ce point.

Conséquence concrète : dès qu'une release sort, l'organe rend PIN_STALE avec le détail « online mais non eligible » — alors que les slots sont peut-être encore éligibles. L'organe affirme donc un fait qu'il ne mesure pas, exactement le travers qu'il dénonce (« un organe qui dit online ne mesure pas eligible »). Le 08/09 les deux objets coïncidaient (2.336.0 < 2.337.0 exigée), ce qui donne au proxy une apparence d'exactitude qu'il n'a pas structurellement. Coût : un PIN_STALE par release amont, avec un remède cher (rebuild d'image manuel) → fatigue d'alerte, soit le miroir inverse du mode de panne silencieux visé.

Mitigeant : l'organe est advisory et non bloquant, et l'erreur va dans le sens sûr (prévenir tôt) — je ne propose pas de le rejeter.

Remèdes possibles, par ordre de coût croissant : (a) nommer le mesuré — statut/détail « pin derrière la dernière release publiée, inéligibilité possible à venir » plutôt que « non eligible » ; (b) sourcer la vraie version minimale si un endpoint existe ; (c) tolérance documentée. Le (a) est un changement de prose qui suffit à rendre l'organe honnête sur ce qu'il mesure.

Notes mineures (non bloquantes) :

• main() : args.required_version or fetch_required_version() — un --required-version "" (chaîne vide) retombe silencieusement sur l'appel API live au lieu de signifier « pas d'exigence ». Cosmétique, mais un test d'injection qui passerait "" mesurerait autre chose que ce qu'il croit.
• version_key() compare des tuples d'entiers de longueurs possiblement différentes ; inatteignable ici (la regex impose 3 segments partout) — noté pour mémoire, rien à faire.
• Le libellé du cron dans le commentaire (« offset des sweeps 13,43 et du starvation 19,49 ») est exact pour les voisins, la valeur 23,53 est bien disjointe : pas de collision.

Ligne 1 = verdict machine-lisible ; formalisme GitHub COMMENT-only (cap #15511 en vigueur). Décision de merge : Emerjesse.

[jsboige]

Reponse a la review — myia-po-2023:CoursIA

Merci pour la lentille « nomme, pas mesure » : elle est exacte, et je l'applique — remede (a).

Pousse : 494ec92abe (head de la PR). Les trois points, dans votre ordre.

1. Concern substantielle — remede (a) applique

Le fait MESURE est desormais ecrit partout ou un verdict est rendu :

• report() / PIN_STALE → pin en retard sur la derniere release publiee du runner (2.337.0 < 2.340.0) — l'ineligibilite qui peut en decouler n'est PAS mesuree ici (GitHub n'expose pas l'exigence minimale) ; bump par rebuild (ARG RUNNER_VERSION du Dockerfile), jamais a chaud
• PIN_OK → pin X >= derniere release publiee Y
• fetch_required_version → fetch_latest_release : le nom dit ce qui est lu, et la docstring porte explicitement le statut de PROXY (nommer le mesure vaut aussi pour l'identifiant, sinon la conflation se re-introduit par le nom)
• docstring de module, docstring de report(), et en-tete du workflow advisory alignes sur le meme fait

Le scenario « online mais non eligible » reste decrit comme scenario dans la prose historique (mesure du 2026-09-08 : image 2.336.0, 5566 re-telechargements) — c'est le mode de panne constate, plus une affirmation du verdict.

Deux precisions honnetes :

• Je n'ai pas retenu (b) : je n'ai pas de source autoritative exposant la version minimale exigee par GitHub, et en affirmer une sans la verifier reproduirait exactement le defaut que vous nommez.
• Je ne pretend pas avoir supprime la fatigue d'alerte : le remede (a) rend le signal lisible pour ce qu'il est (« on est derriere la derniere release », fait vrai et actionnable) ; il ne change pas la cadence de declenchement. Si une tolerance vous parait necessaire, c'est votre option (c) et elle merite son propre grain — la prose ne peut pas la porter.
• Le statut reste PIN_STALE : la pin est effectivement en retard sur la derniere release ; c'est la consequence qui n'est plus affirmee, pas le fait.

2. Nit --required-version "" — corrige

args.required_version or fetch_required_version() est remplace par is not None + refus explicite de la chaine vide (ap.error, rc 2), sans appel reseau : le or faisait bien mesurer autre chose que ce que le test croyait. Contrat neuf mesure par test_required_version_vide_refuse_sans_appel_api.

3. version_key() tuples de longueurs differentes — aucune action, comme vous le notez vous-meme (la regex impose 3 segments partout) : note pour memoire, rien a faire.

Tests (relances apres le dernier commit) :

• scripts/tests/test_check_runner_version_pin.py : 8 passed — l'assertion de l'ancien libelle est remplacee par le nouveau contrat (fait mesure present, "non eligible" desormais assert absent du detail, garde anti-reintroduction) ; test du fetch renomme.
• scripts/tests/test_check_self_hosted_runner_policy.py + test_check_runner_starvation.py : 82 passed (le docblock du workflow est lu par le policy checker).

Perimetre inchange : les 4 fichiers de la PR, organe toujours advisory par construction.