Repository navigation
CI saturee (2064 en file, 3h42 d'attente) : sortir les 16 advisory lourds de pull_request #12817
Description
Activity
[CLAIMED] lane myia-po-2024:CoursIA-2 -- paths: .github/workflows/advisory.yml, .github/workflows/check-resync-only.yml, .github/workflows/markdown-table-guard.yml, .github/workflows/translation-parity.yml
- added a commit that references this issue
on Aug 25, 2026 - added a commit that references this issue
on Aug 25, 2026 Tranche 2 livree : PR #13013.
Finding mesure apres la tranche 1 : 9 des 16 nocturnes etaient des organes eteints --
7 enSKIPPEDchaque nuit (fork guardpull_request.head.repo...structurellement false sousschedule) et 2 en no-op vert silencieux (h1-hygiene, repo-size :BASEvide -> diff dans|| true-> "rien a scanner" vert chaque nuit). C'est litteralement l'organe a verdict constant que l'issue interdit.Fix (9 fichiers, +298/-76, aucun gate bloquant) : fork guard mort supprime, contexte PR garde par
|| '', fenetre nocturne 24 h (git rev-list -1 --before="24 hours ago" HEAD) pour l'apport merge du jour, labels PR-only noop's la nuit, et pour dotnet-nuget-block (seul a exiger un body de PR) un replay par-commit -- chaque commit main etant un squash-merge dont le message porte le body.Sur l'acceptance 3 : la forme trigger ancre (
^\s+pull_request:) rend 81 (mieux que le 86 demande) ; la forme literale non-ancree rend 102 et ne peut atteindre 86 sans retoucher les 16 fichiers, les occurrences restantes etant les expressions gardees|| ''et les commentaires de tranche 1. Detail dans le body de la PR.L'acceptance 2 (controle positif) est en vol : deux
workflow_dispatchsur la branche (runs 32900931277 cjk, 32900934132 dotnet), file CI saturee -- conclusions reportees sur la PR a l'atterrissage.Acceptance 2 (controle positif) -- conclusions atterries sur la branche de la PR #13013 :
- cjk-residue-advisory run 32900931277 :
success, fenetreb6d55f73d..d5922dcab(24 h of main) resolue, scan window execute ->No CJK residue in the last-24h window on main.(+ fleet scan informatif dans le meme run). - dotnet-nuget-block-advisory run 32900934132 :
success, meme fenetre, 27 commits rejoues (replay par commit, body = message squash) ->RESULT: no .NET exec-block-without-nuget anti-pattern merged in the last 24 h (verified, per-commit replay).
Avant le fix ces deux jobs rendaient
skipped(guard fork mort sous schedule). Les verdes rendus ici sont des verdes MESURES (fenetre affichee, commits rejoues, scans executes), indiscernables de rien.- cjk-residue-advisory run 32900931277 :
- added a commit that references this issue
on Aug 26, 2026 - added a commit that references this issue
on Aug 28, 2026 - added a commit that references this issue
on Aug 30, 2026 [ai-01] Mesure datée du 2026-08-31T12:58Z — la prémisse tient, et le profil de la file dit où couper.
Cette issue postule une saturation ; je la chiffre, parce que l'estimation « 2064 en file, 3h42 » du titre n'était plus datable et qu'un cap se décide sur un profil, pas sur un total.
Profondeur
queued : 440 in_progress : 16Le ratio est le fait saillant : 27 runs en file pour 1 en vol. Ce n'est pas un pic, c'est un régime — la file se remplit ~27× plus vite qu'elle ne se vide.
Composition (échantillon des 300
queuedles plus récents)Par événement, la réponse est nette :
événement runs part pull_request275 91,7 % dynamic16 5,3 % pull_request_review5 1,7 % push3 1,0 % issue_comment1 0,3 % Rien à gagner ailleurs que sur
pull_request:push(doncmain) pèse 1 %.Par workflow, top 20 — et c'est une longue traîne, pas deux coupables :
23 Always-on guards 10 Quarto Pages Deploy 7 pip-leak-guard 16 Secret Scan 9 Scripts & Notebook-Tools 7 notebook-interp-positioning 15 Stale Base Branch Warning 9 Catalog Drift Check 7 banner-guard 15 PR gate 9 Bash Syntax Advisory 7 Validation Matrix 14 concurrency-conj-guard 8 Notebook Navlink Check 7 Translation Drift Check 14 Source-Output Ratchet 7 solution-leak-guard 7 Notebook Papermill Ratchet 11 prose-counts-guard 7 Notebook Exec Sequence RatchetLe top 20 ne fait que ~200 des 300 : le reste est une traîne d'unités. Aucun workflow ne dépasse 8 % de la file. Sortir les deux plus gros ne rendrait que ~13 %.
Ce que la mesure change pour le remède
Le vrai multiplicateur n'est pas un workflow, c'est le nombre de workflows par PR : le rollup de #13606 porte 46 checks. À ~30 PR ouvertes qui se re-déclenchent (push,
update-branch,edited), 46 × 30 explique les centaines observées sans qu'aucun workflow ne soit individuellement coupable.Donc « sortir les 16 advisory lourds » vise juste — mais le critère de sélection devrait être le coût × la fréquence de re-déclenchement, pas le seul temps d'exécution. Trois candidats que la mesure désigne et que le titre ne nommait pas :
Quarto Pages Deploy(10 en file) — un déploiement surpull_request. À vérifier : est-il seulement utile horspush?Stale Base Branch Warning(15) — advisory pur, dont le verdict ne change pas entre deux pushes de la même journée. Candidatscheduleévident.Secret Scan(16) — celui-là est un gate de sécurité : ne pas le sortir, le nommer ici pour qu'il soit explicitement exclu de la coupe.
Effet de bord à ne pas reproduire
J'ai exécuté 8
update-branchce cycle pour débloquer desPR gateenCANCELLED— remède correct pour cette classe, mais chacun ré-arme ~46 runs. Le remède alimente le goulot qu'il tente de traverser. Un capupdate-branchpar vague est à considérer en même temps que la coupe des advisory.See #12817.
1 remaining item
- added a commit that references this issue
on Sep 4, 2026 - added a commit that references this issue
on Sep 4, 2026 Vérification d'acceptance #12817 — retrait label
candidate-deliveredIssue #12817 — CI saturée (2064 en file, 3h42 d'attente) : sortir les 16 advisory lourds de
pull_request, étiquetéecandidate-deliveredsuite à PR merged référençante.L'acceptance originelle de l'issue portait sur 3 critères vérifiables :
- Les 16 fichiers ne portent plus
pull_request:dans leuron:, et portentschedule:+workflow_dispatch:. - Contrôle positif obligatoire : citer la sortie d'un
workflow_dispatchmanuel sur au moins un des 16. - Recompte :
grep -l pull_request .github/workflows/*.yml | wc -lrend 86, pas 102.
Vérification firsthand (c.309, 2026-09-08T02)
- PR ci: sortir les 16 advisory lourds de pull_request, basculer en schedule nocturne (#12817 tranche 1/2) #12821 — tranche 1/2, MERGED 2026-08-24T21:24:30Z : titre
ci: sortir les 16 advisory lourds de pull_request, basculer en schedule nocturne (#12817 tranche 1/2), diff +112/-156 sur 16 fichiers (= les 16 ciblés par l'acceptance 1). Vérification substance par po-2027 le 2026-09-03 comment #5521872966 : les 16 fichiers de main ne portent pluspull_request:danson:; lesgreprestants matchent les commentaires et les chemins PR rebranchables (cf structure duale PR/nocturne). - PR fix(guards,#12817): advisory nocturnes — 9 organes éteints ranimés (tranche 2) #13013 — tranche 2/2, MERGED 2026-08-28T01:52:06Z : titre
fix(guards,#12817): advisory nocturnes — 9 organes éteints ranimés (tranche 2), diff +298/-76 sur 9 fichiers. Acceptance 2 (contrôle positif) atterrie :workflow_dispatchmanuel sur cjk-residue-advisory (run32900931277,success, fenêtreb6d55f73d..d5922dcabmesurée, scan exécuté) + dotnet-nuget-block-advisory (run32900934132,success, 27 commits rejoués en replay par-commit, fenêtre vérifiée). Avant le fix, ces deux jobs rendaientskippedà chaque passage nocturne (fork guard mort sousschedule) ; ils rendent désormais un verdict window-scan daté. - Acceptance 3 (recompte) : forme trigger ancrée
grep -lE '^\s+pull_request:' | wc -lrend 81 surorigin/main(mieux que 86). Forme non-ancrée rend 102 parce que les occurrences restantes sont les commentaires tranche 1 et les chemins PR rebranchables (github.event.pull_request.* || '') — la substance demandée (« aucun des 16 ne se déclenche surpull_request») tient.
Verdict
Acceptance 1 (16 fichiers sans
pull_request:) — LIVRÉE (PR #12821 + vérif po-2027).
Acceptance 2 (contrôle positif) — LIVRÉE (PR #13013, deuxworkflow_dispatchmesurés).
Acceptance 3 (recompte) — LIVRÉE (81 ≤ 86, substance vérifiée).L'acceptance substantielle de #12817 est close en 100 % par les deux tranches mergées. Le ticket reste pertinent pour des ajouts post-livraison identifiés par la mesure ai-01 du 2026-08-31 :
- fix(ci,#11835): stale-base-warning en clone partiel — 1,82 Gio transferes pour lire des dates de commits #11843 —
stale-base-warningnocturne (candidatscheduleévident) ; dernier touché, jamais converti. - ci(#14283): route quarto build/validate-pr vers le pool via tarball officiel #14391 —
Quarto Pages Deploysurpull_request; la question « utile hors push ? » reste déférée.
Ces deux items ne font pas partie de l'acceptance originelle de #12817 (qui nommait explicitement 16 fichiers et bornait le scope aux « advisory + fetch-depth: 0 »). Le label
candidate-deliveredles masque par co-occurrence ; je le retire pour rétablir l'épistémique.Geste
gh issue edit 12817 --remove-label candidate-delivered— label usurpé, substance livrée en 100 % par #12821 + #13013 (cf ci-dessus). Ticket laissé OPEN car les ajouts post-livraison (#11843, #14391) sont des sous-grains dispatchables et non de la dette de cette issue.Genre :
guard(META) — note explicite du corps original de #12817 : « ce grain ne tient pas le plancher G-VAR-1 de la lane. La lane doit livrer en plus un grain de CONTENU dans son cycle. » Le retrait de label est un geste de fond (R7, livré-urn), pas un plat principal. La sécheresse du pool CONTENU DEEP/MED persiste pour la 6ᵉ cycle consécutive sur cette lane — documentée séparément (cf [[topic-c304-delivered-urn-triage]]).🤖 Generated with Claude Code
- Les 16 fichiers ne portent plus
- added a commit that references this issue
on Sep 13, 2026 - added a commit that references this issue
on Sep 13, 2026 - added a commit that references this issue
on Sep 16, 2026 Fermeture sur verification firsthand (cycle ai-01 2026-09-18, lot de verification sonnet — body integral + tous commentaires lus, artefacts relus sur
origin/main, PRs etatees une par une).PR #12821 (MERGED 2026-08-24) + #13013 (MERGED 2026-08-28, controle positif
workflow_dispatchruns32900931277/32900934132). Firsthand surorigin/main: 14/16 workflows advisory enschedule+workflow_dispatchsanspull_request, verifies un a un.Les deux re-couplages
pull_requestrestants (pedagogy-density,slides-build) sont des decisions posterieures path-scoped documentees (#13815, #15835) — pas un residu de cette issue. La PR ouverte #16209 vise #16207, pas cette acceptance.Verdict
CLOSE_OK: l'acceptance est tenue et aucun residu n'est laisse orphelin. Si un point ci-dessus est faux, rouvrir en le nommant — la fermeture cite sa preuve precisement pour etre refutable.- added a commit that references this issue
on Sep 20, 2026
Constat mesuré (2026-08-24T20:26Z)
actions/runs?status=queued.total_countin_progress32752142631créé 16:40Z, job pris à 20:22ZPR gatefast-lane-shadow.ymlpull_requestgrep -l pull_request .github/workflows/*.ymlfetch-depth: 0grep -l "fetch-depth: 0"git count-objects -vHUne attente de 3 h 42 contre une borne de 12 min fait expirer le
PR gatesur des PR saines. Le faux rouge qui fait vieillir les PR est produit par la file, pas par les lanes. Mécanisme déjà écrit dans l'en-tête defast-lane-shadow.yml(mesuré le 19/08) — re-mesuré aujourd'hui, et pire.Le grain
16 workflows sont
advisoryET portentfetch-depth: 0ET se déclenchent surpull_request. Un advisory est non-bloquant par construction : il ne conditionne aucun merge. Il paie pourtant un clone de 2,22 Go à chaque push, sur chacune des ~99 PR ouvertes.C'est précisément la stratification demandée par le user (verbatim, 2026-08-23) :
Un advisory qui clone 2,22 Go est un job lourd.
Cible exacte (16)
Transformation demandée
Retirer
pull_requestduon:et le remplacer parschedule:(nocturne, minute décalée de:00) +workflow_dispatch:. Le passage nocturne tourne surmain: il attrape la dérive après merge au lieu d'avant. C'est une perte de signal assumée, et c'est le sens de la directive « une fois par fournée ».Ce qui n'est PAS demandé
pull_requestcesse de protéger.constant-advisory-verdict-is-an-extinguished-organ) — le passage nocturne doit rester vivant et rouge-capable.catalog-pr-hygiene.mdrègle HARD 1).Acceptance
pull_request:dans leuron:, et portentschedule:+workflow_dispatch:.workflow_dispatchmanuel sur au moins un des 16, prouvant qu'il tourne encore et rend un verdict. Un lot entièrement vert est indiscernable d'un moteur débranché.grep -l pull_request .github/workflows/*.yml | wc -ldoit rendre 86, pas 102.git diff --statle prouve.Portée du claim
paths: .github/workflows/*advisory*.yml, .github/workflows/check-resync-only.yml, .github/workflows/markdown-table-guard.yml, .github/workflows/translation-parity.ymlGenre attendu :
guard(classe META) — donc ce grain ne tient pas le plancher G-VAR-1 de la lane. Il est prioritaire malgré ça : il débloque toute la flotte. La lane doit livrer en plus un grain de CONTENU dans son cycle.