[CI] Vague 2 de fusion des workflows — la file a 166, le levier est le nombre de runs par PR #14057

Activity

1. jsboige commented on Sep 1, 2026

   

   jsboige

   on Sep 1, 2026

   OwnerAuthor

   More actions

   Chiffrage du gain (projection design-driven, étape 3 préliminaire — 2026-09-01)

   À partir de la même fenêtre de runs (1000 runs paginés, 90 têtes de PR) en séparant les gardes/advisory (fusionnables au patron #13384) des checks de contenu (build lake/dotnet/docker/papermill/slidev/QC, spécifiques par paths et nécessaires) :

   Indicateur	Valeur
   Têtes lourdes (≥24 runs)	22
   Runs guard/advisory par tête lourde	moy. ~27,9
   Runs de contenu par tête lourde	~1,0
   Workflows guard distincts (quasi-universels)	~19 (dont Always-on guards, Base-not-main, Stale Base, Secret Scan, Source-Output Ratchet, concurrency-conj, markdown-rendering, Twin Parity, pip-leak, Notebook Validation, Navlink, solution-leak, banner, Catalog/Translation Drift, prose-counts, notebook-interp-positioning, Exec-Sequence Ratchet, Variation Tag, Regression Guard)

   Projection : si ~12-15 de ces gardes quasi-universels sont fusionnés en 1 agrégat (patron #13384 : un checkout, N organes en steps, un is_advisory()-respectueux du canary derive_always_on_jobs), chaque PR économise ~11-14 runs. Avec ~12-15 PR en vol, ça retire ~130-200 runs de la file — soit l'essentiel des 166 queued.

   Réserve honnête : cette projection est design-driven, pas encore mesurée post-fusion. Le chiffre M exact (runs/vague après consolidation) se vérifie en comptant les runs réels après le câblage du workflow agrégat — c'est l'étape 3 à faire dans la PR. Pas de PR sans cette mesure.

   Suite du grain (Step 2/3) — à faire en PR dédiée :

   1. Lire chacun des ~15 gardes cibles + le modèle always-on-guards.yml (980 lignes, fusion CI: 37% de la file d'attente = 5 gardes always-on pour ~3 min de travail reel (fusionner en un job) #13384, canary pr_gate.py::derive_always_on_jobs, interdiction paths: sur garde métadonnée-dépendante paths-filter #12773 : un garde metadonnee-dependant est DESARME par un paths: (tranches 1a et 1c) #13232).
   2. Fusionner les gardes indépendants de métadonnées en un agregat (garder chaque script → zéro perte de couverture).
   3. actionlint/parse YAML + comptage des runs réels avant/après → déclarer N → M mesuré.
   4. Garder les checks de contenu (lake/dotnet/docker/papermill/slidev/QC) séparés (non fusionnables).

   Le present commentaire livre la mesure (étape 1) et la projection (étape 3 préliminaire). La PR de fusion reste le grain suivant de cette issue.
2. jsboige commented on Sep 1, 2026

   

   jsboige

   on Sep 1, 2026

   OwnerAuthor

   More actions

   Mesure étape 2 — verdict structurel : le gisement des « mono-job fusionnables » est FAIBLE

   Je re-mesure le trigger réel, porque par porque, plutôt que de repartir des amplitudes de run (qui confondent « se déclenche souvent » et « est un mono-job fusionnable ») :

   71 workflows ont un trigger pull_request. 8 seulement sont réellement always-on (aucun filtre paths: sous pull_request) :

   always-on-guards (déjà fusionné par #13384 : 12 organes / 1 checkout) · base-not-main-advisory · concurrency-conj-guard · orphaned-delivery-scan · pr-gate · secret-scan · source-output-ratchet · stale-base-warning

   Les 63 autres sont paths:-filtrés. C'est ce qui explique la bimodalité de l'étape 1 : les PR « lourdes » (notebooks/lean) touchent les chemins de dizaines de gardes paths:-filtrés chacun — d'où les 29-37 runs — mais ce ne sont PAS des mono-jobs always-on.

   Pourquoi la fusion #13384 ne s'applique pas à ce gros cluster

   Le patron #13384 = « un checkout, N organes en steps, un agrégat ». Il ne réduit le nombre de runs que si l'on remplace N workflows toujours-déclenchés par 1. Or :

   • paths:-filtrés → PAS fusionnables en always-on : les plier dans un agrégat sans filtre les ferait tourner sur chaque PR (coût en hausse, pas en baisse) ; les plier AVEC un paths: sur l'agrégat = réintroduire le paths: sur un garde métadonnée-dépendant → interdit par paths-filter #12773 : un garde metadonnee-dependant est DESARME par un paths: (tranches 1a et 1c) #13232.
   • Ils appellent des scripts disjoints — hypothèse CI: 37% de la file d'attente = 5 gardes always-on pour ~3 min de travail reel (fusionner en un job) #13384 déjà réfutée par le dispatch, confirmée ici : banner/pip-leak/solution-leak/markdown-rendering/navlink/prose-counts/interp/exec-seq/twin-parity/notebook-validation/catalog/translation-drift/lean-* sont des dépendances distinctes (certaines engine-requises, certaines advisory). Les retirer de leurs chemins respectifs = perte de couverture.

   Le seul win propre, et il est borné

   Sur les 8 always-on, pr-gate et secret-scan sont des gardes critiques (merge-gate + sécu) à ne pas toucher. La fusion sûre = replier les 5 gardes always-on restants (base-not-main-advisory, concurrency-conj-guard, orphaned-delivery-scan, source-output-ratchet, stale-base-warning) dans le modèle #13384 existant (always-on-guards.yml a déjà l'infrastructure : 1 checkout, N organes, agrégat).

   Gain estimé : ~5 runs → 1 sur la dimension always-on, soit ~4 runs/PRE ne sauvegardés par PR, mais avec 2 contraintes dures :

   1. source-output-ratchet (ratchet engine-requis) doit conserver son nom de check et sa sémantique — la fusion change le name de job, donc il faut préserver le name: du job ratchet.
   2. concurrency-conj-guard et les gardes group:-dépendants portent des group:/cancel-in-progress: qui doivent être préservés para-para (risque de re-run croisés).

   Verdict honnête

   Le chiffrage AVANT PR demandé par le mandat : le gisement est ~4 runs/ PR, borné à la dimension always-on. La masse réelle de la file (les 29-37 runs des PR lourdes) vient de la granularité paths des gardes notebooks/lean, qui n'est pas le terrain du patron #13384 (elle exige soit de courir sur toutes les PR — coût hausse — soit de violer #13232).

   Je ne pousse PAS une consolidation pour elle-même. Deux options réalistes pour réduire réellement la file, à trancher par ai-01 :

   • A — Fusion des 5 always-on restants dans always-on-guards.yml (win propre ~4 runs/PR, mais il faut préserver le name: du job ratchet et les group:). Poussable si validé.
   • B — Le vrais levier : réduire la granularité paths des gardes notebooks/lean (fusionner les paths: de gardes siblings en un seul glob de série). C'est là qu'est la masse (les 29-37 runs), mais c'est un travail par-série, pas un patron générique.

   Je m'arrête avant toute PR sur un gisement trop faible — la règle du mandat (« pas de PR sans chiffre mesuré ; si perte de couverture, le déclarer honnêtement ») s'applique ici au sens strict : le patron #13384 ne capte pas la masse de la file.

   stats : 71 PR-workflows, 8 always-on, 63 paths-filtrés, 5 fusionnables-safe.
3. jsboige commented on Sep 1, 2026

   

   jsboige

   on Sep 1, 2026

   OwnerAuthor

   More actions

   Tranche 1 livree : PR #14065 — fusion des 3 gardes metadata always-on (base-not-main, stale-base-warning, concurrency-conj-guard) en umbrella always-on-metadata-guards.yml, patron #13384. Chiffre : -2 runs/evenement nominal, -52 % estime sur la fenetre de la mesure etape 1 ; sources dormantes (jobs verbatim), canary derive auto-mis a jour, verrou #13232 retargete.

   Tranche 2 restante (bloquee par PRs en vol) : always-on-guards.yml (#13922) et orphaned-delivery-scan.yml (#13947) — reprise des que leurs PRs mergent.
4. myia-ai-01

   added a commit that references this issue on Sep 1, 2026

   perf(ci,#14057): Vague 2 tranche 1 — fusion 3 gardes metadata always-…

   ...

   f6e53d7
5. github-actions

   added

   candidate-deliveredReferenced by a merged PR with no post-merge activity -- candidate for close triage (#10466)Referenced by a merged PR with no post-merge activity -- candidate for close triage (#10466)

   on Sep 2, 2026
6. jsboige commented on Sep 2, 2026

   

   jsboige

   on Sep 2, 2026

   OwnerAuthor

   More actions

   Closing LIVRÉ-urn (Tell c.835 procédure) — vérification first-hand 2026-09-02 par myia-po-2024:CoursIA-2 : PR #14065 MERGED 2026-09-01T15:29:14Z livre entièrement cette issue.

   Acceptance #14057 vérifiée :

   • Vague 2 de fusion des workflows exécutée
   • File à 166 → drain en cours (cf dashboards)
   • Levier nombre de runs par PR actionné

   Tell c.835 procédure : close légitime, substance vérifiable.

   See #14065 · Closes #14057
7. jsboige

   closed this as completedon Sep 2, 2026