Constat
La jambe CI Audit README -> .ipynb links (workflow .github/workflows/readme-ipynb-links-guard.yml, job declare timeout-minutes: 5 a la ligne 57) est annulee par son propre plafond des que le parc de runners est sature, et cette annulation est ensuite reportee par le PR gate comme un echec bloquant :
##[error][pr-gate] FAIL -- checks that hit their declared timeout-minutes:
Audit README -> .ipynb links (cancelled, 6m19s, declared timeout-minutes: 5)
-- rerunning the gate re-reads the same frozen check-run: rerun the CHILD run
that owns the job (gh run rerun <id>), never the gate (#15905)
Le message est explicite : ce n'est pas un finding, c'est une jambe qui a depasse son propre plafond. Le gate le nomme faute de pouvoir distinguer une annulation-par-plafond d'un echec reel.
Mesure (PR #19601, tete 0f1ccc46bc)
| Fait |
Mesure |
| Jambe d'origine |
job 113514130318, started 2026-10-08T20:01:39Z, cancelled 20:07:58Z -> 6 m 19 s contre un plafond declare de 5 min |
| Gate qui la reporte |
run 37836317448 / job 113514118557, started 20:03:06Z, completed 20:08:32Z — il lit la check-run figee (annulee) et rend failure |
| Rejeu de la jambe enfant (geste prescrit par le gate) |
job 113518292412, 20:11:08Z -> 20:12:44Z, success, 7 pas peuples |
| Consequence |
le gate, lui, reste rouge jusqu'a un nouveau run : sa lecture predate le rejeu de la jambe |
La meme jambe avait deja ete annulee par plafond sur la meme PR a 16:46Z. Elle est par ailleurs verte des dizaines de fois par heure sur la flotte aux heures creuses : la duree depend de la contention, pas du contenu de la PR.
Pourquoi c'est structurel
Le workflow rend un site/document entier (quarto render) et scanne le corpus README -> .ipynb (plus de 8000 liens). Hors contention il tient largement sous 5 min ; sous contention (files de plusieurs dizaines de runs, cf. le parc charge de la journee) il les depasse, est annule, et le PR gate transforme l'annulation en rouge bloquant pour la PR. Toute PR touchant un README herite donc d'un rouge fantome qui :
- n'accuse pas le livrable,
- ne se leve pas par
gh run rerun du gate (le message le dit : la check-run est figee),
- exige un rejeu de la jambe enfant, geste que peu de lanes connaissent.
Correctif propose
Elever le plafond de cette jambe a une valeur qui couvre la contention mesuree (par ex. timeout-minutes: 12 — la duree normale est de l'ordre de la minute, le plafond n'est qu'un garde-fou anti-blocage), sans toucher aux autres jambes. Alternative ou complement : faire distinguer par le PR gate une cancelled-sur-plafond d'un failure reel (une cancelled de plafond ne devrait pas etre un rouge bloquant, ou devrait etre re-roulee automatiquement une fois).
Acceptance
- une PR touchant un README ne peut plus obtenir un
PR gate rouge dont le seul motif est checks that hit their declared timeout-minutes: Audit README -> .ipynb links ;
- verification : sur une fenetre de forte contention, la jambe se termine (
success ou echec reel nomme) au lieu d'etre annulee par plafond.
Sans parent : fragilite d'infrastructure mesuree en cycle, non rattachee a une EPIC ouverte. Le correctif est une PR ci(...) d'une ligne, retenue par le plafond WIP de la lane qui l'a mesuree.
🤖 Generated with Claude Code
Constat
La jambe CI
Audit README -> .ipynb links(workflow.github/workflows/readme-ipynb-links-guard.yml, job declaretimeout-minutes: 5a la ligne 57) est annulee par son propre plafond des que le parc de runners est sature, et cette annulation est ensuite reportee par lePR gatecomme un echec bloquant :Le message est explicite : ce n'est pas un finding, c'est une jambe qui a depasse son propre plafond. Le gate le nomme faute de pouvoir distinguer une annulation-par-plafond d'un echec reel.
Mesure (PR #19601, tete
0f1ccc46bc)113514130318,started 2026-10-08T20:01:39Z, cancelled20:07:58Z-> 6 m 19 s contre un plafond declare de 5 min37836317448/ job113514118557,started 20:03:06Z,completed 20:08:32Z— il lit la check-run figee (annulee) et rendfailure113518292412,20:11:08Z -> 20:12:44Z, success, 7 pas peuplesLa meme jambe avait deja ete annulee par plafond sur la meme PR a
16:46Z. Elle est par ailleurs verte des dizaines de fois par heure sur la flotte aux heures creuses : la duree depend de la contention, pas du contenu de la PR.Pourquoi c'est structurel
Le workflow rend un site/document entier (
quarto render) et scanne le corpus README ->.ipynb(plus de 8000 liens). Hors contention il tient largement sous 5 min ; sous contention (files de plusieurs dizaines de runs, cf. le parc charge de la journee) il les depasse, est annule, et lePR gatetransforme l'annulation en rouge bloquant pour la PR. Toute PR touchant un README herite donc d'un rouge fantome qui :gh run rerundu gate (le message le dit : la check-run est figee),Correctif propose
Elever le plafond de cette jambe a une valeur qui couvre la contention mesuree (par ex.
timeout-minutes: 12— la duree normale est de l'ordre de la minute, le plafond n'est qu'un garde-fou anti-blocage), sans toucher aux autres jambes. Alternative ou complement : faire distinguer par lePR gateunecancelled-sur-plafond d'unfailurereel (unecancelledde plafond ne devrait pas etre un rouge bloquant, ou devrait etre re-roulee automatiquement une fois).Acceptance
PR gaterouge dont le seul motif estchecks that hit their declared timeout-minutes: Audit README -> .ipynb links;successou echec reel nomme) au lieu d'etre annulee par plafond.Sans parent : fragilite d'infrastructure mesuree en cycle, non rattachee a une EPIC ouverte. Le correctif est une PR
ci(...)d'une ligne, retenue par le plafond WIP de la lane qui l'a mesuree.🤖 Generated with Claude Code