fix(ci,#15941): align runner-starvation-advisory on its 2-label matrix, drop the inert guard

[jsboige]

Grain: LIGHT/tooling — lane myia-po-2026:CoursIA — prev: DEEP/slides #15865

Résumé

runner-starvation-advisory.yml annonçait trois labels (waiter+linux+lean) alors que sa matrice en porte deux — et sa garde pull_request ne pouvait jamais être fausse. Les quatre passages concernés sont alignés sur la matrice, et la garde inerte est retirée.

Closes #15941

1. Le compte de labels — l'issue en relevait trois, le fichier en porte quatre

L'issue nommait l.1, l.11-12 et l.26. Le passage l.14-16 portait le même défaut sans être relevé :

# Pourquoi une matrice et pas 3 workflows dedies : ...
# l'observabilite, les 3 sondes partagent la fenetre STARVATION ...
# RUNNERS_READ_PAT, et la matrice GitHub Actions parallellise les 3 mesures

Trois « 3 » supplémentaires, invisibles parce qu'ils ne sont pas dans le voisinage du name:. Corrigé aussi.

Passage	Avant	Après
l.1 (et son écho l.53 job name)	(waiter+linux+lean)	(waiter+lean)
l.11-12	« aux 3 labels … (linux, lean) »	« a deux des trois labels … (lean) ; coursia-linux reste couvert par son workflow dedie (linux-runner-starvation-advisory.yml, cron 19,49) »
l.14-16	« pas 3 workflows dedies … les 3 sondes … les 3 mesures »	« pas 2 … les 2 sondes … les 2 mesures »
l.26	« waiter = 1, linux = 2, lean = 1 »	« waiter = 1, lean = 1 »

Contrôle positif dans le fichier lui-même : l.17 disait déjà correctement « 23,53 pour les 2 autres ». Le fichier était donc intérieurement incohérent — « 2 » est bien l'intention, pas une préférence de relecture.

Le workflow dédié existe bien (vérifié sur origin/main) : linux-runner-starvation-advisory.yml, name: Linux runner starvation advisory, cron 19,49 * * * *, mesure coursia-linux. Le remède « reformuler vers deux labels » est donc vrai, pas supposé.

2. La garde inerte — retirée, et la décision est mesurée

La garde ne peut jamais être fausse : les seuls triggers sont schedule + workflow_dispatch (l.36-39), donc github.event.pull_request est absent, head.repo.full_name vaut null, et la branche == null est vraie par construction.

Le remède n'était pas évident — la garde est un idiome à l'échelle de la flotte. Quatre vérifications, pas une intuition :

1. Le garde qui possède la question ne l'exige pas. scripts/ci/check_self_hosted_runner_policy.py : « Every pull_request job must also carry the exact same-repository guard … checked for the same-repo guard when pull_request is present » (docstring l.8-12). Ses entrées schedule-only disent explicitement « Aucun trigger pull_request -> aucune garde same-repo requise » (l.153-155, l.168, l.188).
2. La retirer ne périme aucune prose. Le registre d'allowlist porte une ligne « garde same-repo au niveau job malgre l'absence de trigger pull_request » — mais elle appartient à l'entrée linux-runner-version-pin-advisory.yml (l.233-242), pas à mon fichier. L'entrée de runner-starvation-advisory.yml (l.244-263) dit déjà « 2 labels waiter + lean (matrice GitHub Actions, 2 entrees include) » — donc la prose du registre était déjà correcte et le fichier était le seul en retard.
3. L'idiome dominant des advisories schedule-only est sans garde : sur 6 échantillonnées, 4 n'en portent aucune (adjacency-stale-sweep, lane-claim-epic-wide-advisory, pr-gate-stale-sweep, candidate-delivered-advisory) ; les 2 qui en portent sont la lignée linux-runner-*.
4. Personne n'épingle la garde ni le nom : le seul consommateur du fichier est check_self_hosted_runner_policy.py (allowlist par nom de fichier, inchangé) ; check_scheduler_liveness.py n'énumère que la variante linux- ; aucun organe, test ou doc ne référence la chaîne Runner starvation advisory.

Retirer suit aussi la règle maison « soustraire d'abord, n'ajouter que si le retrait laisse un trou réel » : le trou n'existe pas ici (l.32-34 documente déjà l'intention advisory), donc j'ai retiré plutôt qu'annoté.

Validation

Contrôle	Résultat
Parse YAML	name = Runner starvation advisory (waiter+lean) · triggers ['schedule','workflow_dispatch'] · matrice ['coursia-waiter','coursia-lean'] · job if: <absent>
Consommateur réel — python scripts/ci/check_self_hosted_runner_policy.py	[self-hosted-policy] workflows=161 jobs=204 self_hosted=132 / OK -- all self-hosted jobs satisfy isolation policy / rc=0
Tests du garde — scripts/tests/test_check_self_hosted_runner_policy.py	58 passed, dont test_current_repository_self_hosted_jobs_satisfy_isolation_policy = validation sur le corpus réel de workflows, pas sur une fixture
Résidu	grep '3 labels|3 workflows|3 sondes|3 mesures|linux = 2|waiter+linux' → aucun
Épinglage du nom	grep -rn 'Runner starvation advisory' → uniquement les deux auto-références du fichier (l.1, l.53)

Périmètre : 1 fichier, +9/−8. Aucun changement de comportement : deux reformulations de texte, un name: d'affichage, une garde logiquement toujours vraie retirée.

Note

L'issue est un suivi des deux OBS non-bloquantes de la review [NanoClaw] sur #15423. Les deux sont traitées ; le point 1 est élargi d'un passage (voir §1), comme l'avait été le constat de NanoClaw sur le point 1 (commentaire d'en-tête → trois sites → ici quatre).

See #15423 · See #14846

🤖 Generated with Claude Code

[github-actions]

Path-collision (organ #13359/#13615)

Cette PR #15948 (fix(ci,#15941): align runner-starvation-advisory on its 2-label matrix, drop the inert guard) 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.

• fort -- docs(ci,#15941): aligner runner-starvation-advisory sur sa matrice reelle (2 labels) #15947 partage : .github/workflows/runner-starvation-advisory.yml (issues communes : feat(ci,#14846): runner starvation advisory multi-label (waiter+lean) #15423, runner-starvation-advisory.yml : le fichier annonce 3 labels, la matrice en porte 2 — plus une garde pull_request inopérante #15941)