runner-starvation-advisory.yml : le fichier annonce 3 labels, la matrice en porte 2 — plus une garde pull_request inopérante #15941

Suivi des deux OBS non-bloquantes de la review [NanoClaw] sur #15423, ouvert avant le merge de cette PR pour qu'aucune remarque ne reste sans destination. La sonde elle-même est correcte et utile : ce ticket ne porte que sur la lisibilité du fichier, qui compte parce que c'est un fichier qu'on lit à 4 h du matin quand un pool vient de mourir.

Fichier : .github/workflows/runner-starvation-advisory.yml (78 lignes, tel que mergé par #15423).

1. Le fichier annonce trois labels, la matrice en porte deux

La matrice include porte exactement deux entrées :

 62|  - label: coursia-waiter
 63|    warn_floor: 1
 65|  - label: coursia-lean
 66|    warn_floor: 1

coursia-linux reste couvert par son workflow dédié préexistant (linux-runner-starvation-advisory.yml, cron 19,49) — c'est le bon design, et le commentaire du cron le dit correctement (« waiter + lean (offset distinct du cron linux 19,49) »).

Mais trois autres endroits du même fichier annoncent trois labels :

Le name: est le plus gênant des trois : c'est lui qui s'affiche dans l'onglet Actions et dans les notifications. Quelqu'un qui cherche pourquoi coursia-linux n'a pas rougi ira lire ce workflow-là, en conclura qu'il couvre linux, et ne trouvera pas le vrai (qui, lui, a bien rougi ou pas).

Remède : aligner les trois sites sur la matrice — name: Runner starvation advisory (waiter+lean), et reformuler les deux commentaires pour dire « deux des trois labels ; coursia-linux est couvert par linux-runner-starvation-advisory.yml ». Ou, si la jambe linux était réellement voulue ici, l'ajouter à la matrice et supprimer le workflow dédié — mais ce serait un autre grain, plus large, et le cron 23,53 a justement été choisi disjoint de 19,49 pour cohabiter avec lui.

2. Garde pull_request inopérante

 56|  if: github.event.pull_request.head.repo.full_name == null || github.event.pull_request.head.repo.full_name == github.repository

Les seuls triggers du fichier sont schedule et workflow_dispatch (l.36-39). Sur ces événements le contexte pull_request n'existe pas : head.repo.full_name vaut null, la première branche de l'alternative est donc toujours vraie et la condition ne peut jamais être fausse.

C'est une copie de pr-gate.yml sans dommage — la garde anti-fork y a un sens, ici non. Elle est inerte, mais un lecteur suivant peut la prendre pour une protection active et raisonner faux sur ce qui déclenche ce workflow.

Remède : la retirer, ou la remplacer par un commentaire d'une ligne disant que le workflow n'est volontairement pas déclenché par pull_request (l'intention est déjà écrite l.32-34, ce qui rend la garde d'autant plus redondante).

Portée

Deux modifications de texte et une ligne retirée, aucun changement de comportement. Grain LIGHT. Ni l'une ni l'autre ne justifiait de retenir #15423 : la sonde comble une lacune d'incident réelle (05/09, pool coursia-waiter éteint, 28 runners enregistrés / 0 en ligne, 4 h 20 de merges gelés sans qu'aucun check ne rougisse).

See #15423 · See #14846

Relevé par la review [NanoClaw] du 2026-09-09T22:17Z (OBS 1 et 2), constaté firsthand à la tête 3dc888df041c — le point 1 y est élargi : NanoClaw signalait le commentaire d'en-tête, il y a en réalité trois sites divergents dont le name: du workflow.