Symptome
Les PR Quarto ne concluent pas. Leur PR gate -- check requis -- sort cancelled, donc sans verdict, donc la PR reste BLOCKED indefiniment.
Chaine causale, mesuree sur #14225 (2026-09-03)
Un seul train de runs, cree a 04:15:31Z sur la tete f245243bf :
| Etape |
Mesure |
Validate Quarto build (PR) en file |
04:15:31 -> 04:40:29 = 25 min d'attente de slot |
step Render Quarto site (PR check) |
3180 s = 53 min, puis tue par timeout-minutes: 60 |
PR gate (agregateur) |
auto-annule a 45 min faute de verdict (chemin STARVED #13510) |
| Resultat |
check requis cancelled -> aucun verdict -> PR BLOCKED |
Le detail des 60 minutes du job Quarto :
238 s Set up Quarto (retelecharge a chaque job : pool ephemere)
178 s Escape YAML separators
3180 s Render Quarto site (PR check) <- CANCELLED au plafond
Cause
La jambe PR execute quarto render --to html nu. C'est un rendu du site entier :
- 1192 entrees dans
project.render (_quarto.yml)
_freeze/ n'est pas tracke (git ls-tree origin/main -- _freeze/ rend 0 fichier) : rien n'est mis en cache d'un run a l'autre, tout est recalcule a chaque fois
Alors que l'objet declare du job, dans son propre commentaire, est etroit :
« Bloque les PR qui etendent _quarto.yml / ajoutent un notebook / modifient une cellule markdown d'un notebook rendu »
Le job valide donc ce que la PR change, en rendant tout ce qu'elle ne change pas.
Pourquoi relever les plafonds n'est pas le correctif
#14412 a monte Quarto 30 -> 60 et le gate 28 -> 45. C'etait juste face a la mesure d'alors, et ca ne suffit pas : le run ci-dessus a ete tue au nouveau plafond de 60. Surtout, chaque relevement fait tenir un slot auto-heberge une heure entiere par PR Quarto, sur un parc mesure a 19/22 occupes. Le plafond ne cause pas la famine, il la finance.
Mesure de l'ampleur
Le script de scope applique aux 7 PR Quarto en vol ce jour :
Six PR sur sept rendent 1 ou 2 documents utiles sur 1192 (0,08 % a 0,17 %). La septieme, #14131, ne touche aucun document rendu et payait quand meme un rendu complet d'une heure.
Acceptance
Limite assumee
Un rendu scope ne voit pas la casse qu'un fichier change provoque dans un fichier inchange (reference croisee, entree de barre laterale). Cette classe reste couverte par le rendu complet de la jambe deploy sur main -- un merge plus tard au lieu d'une PR plus tot. C'est le bon sens de l'echange tant que l'alternative est une verification qui ne peut pas conclure du tout.
Symptome
Les PR Quarto ne concluent pas. Leur
PR gate-- check requis -- sortcancelled, donc sans verdict, donc la PR reste BLOCKED indefiniment.Chaine causale, mesuree sur #14225 (2026-09-03)
Un seul train de runs, cree a 04:15:31Z sur la tete
f245243bf:Validate Quarto build (PR)en fileRender Quarto site (PR check)timeout-minutes: 60PR gate(agregateur)cancelled-> aucun verdict -> PR BLOCKEDLe detail des 60 minutes du job Quarto :
Cause
La jambe PR execute
quarto render --to htmlnu. C'est un rendu du site entier :project.render(_quarto.yml)_freeze/n'est pas tracke (git ls-tree origin/main -- _freeze/rend 0 fichier) : rien n'est mis en cache d'un run a l'autre, tout est recalcule a chaque foisAlors que l'objet declare du job, dans son propre commentaire, est etroit :
Le job valide donc ce que la PR change, en rendant tout ce qu'elle ne change pas.
Pourquoi relever les plafonds n'est pas le correctif
#14412 a monte Quarto 30 -> 60 et le gate 28 -> 45. C'etait juste face a la mesure d'alors, et ca ne suffit pas : le run ci-dessus a ete tue au nouveau plafond de 60. Surtout, chaque relevement fait tenir un slot auto-heberge une heure entiere par PR Quarto, sur un parc mesure a 19/22 occupes. Le plafond ne cause pas la famine, il la finance.
Mesure de l'ampleur
Le script de scope applique aux 7 PR Quarto en vol ce jour :
Six PR sur sept rendent 1 ou 2 documents utiles sur 1192 (0,08 % a 0,17 %). La septieme, #14131, ne touche aucun document rendu et payait quand meme un rendu complet d'une heure.
Acceptance
quarto rendersur liste vide (qui rendrait le site entier).push/deploy surmaingarde son rendu complet : c'est elle qui couvre la casse cross-fichier.Limite assumee
Un rendu scope ne voit pas la casse qu'un fichier change provoque dans un fichier inchange (reference croisee, entree de barre laterale). Cette classe reste couverte par le rendu complet de la jambe deploy sur
main-- un merge plus tard au lieu d'une PR plus tot. C'est le bon sens de l'echange tant que l'alternative est une verification qui ne peut pas conclure du tout.