Repository navigation
Fix(ci,#12856): absorber les 9 gardes du lot PILOTE dans la fast lane - #20166
Conversation
Path-collision (organ #13359/#13615)Cette PR #20166 (
|
|
G-VAR-2 light cap reached (advisory, non bloquant). |
|
G-VAR-2/3 GENRE signals (advisory, non bloquant, #10020).
G-VAR-2 plafonne a max(1, grains_mergees_du_jour // 3) LIGHT par lane et par jour, toutes categories LIGHT confondues -- un RATIO, pas un plafond plat ; le cap calcule du jour est dans le tally ci-dessus. G-VAR-3 interdit deux genres LIGHT consecutifs. Les signaux ci-dessus rendent le fait VISIBLE (labels |
|
G-VAR-3 : deux grains LIGHT du meme genre consecutifs -- bloquant (#11170). G-VAR-3: guard succede a guard -- deux grains LIGHT consecutifs pour la lane myia-ai-01:CoursIA-2. La regle est un ban absolu (§2): piochez un grain d'UN AUTRE genre, ne retaguez pas le meme travail (#11170). Tenu > 24 h : le coordinateur tranche par Referentiel du verdict (#15739) -- ce verdict a ete calcule contre : predecesseur #20048 ( python scripts/ci/variation_adjacency_guard.py --pr-number 20166variation-protocol.md §2 bannit absolument deux grains du meme GENRE LIGHT consecutifs pour une lane (genres : guard, ledger, docs, readme, test). Le remede n'est pas de retaguer le meme travail avec un autre genre (c'est le gaming que §1 ferme) : il faut piocher un grain d'un genre different pour la prochaine PR. Pour passer ce gate, remplacez la |
|
No organ-duplication: no added def/class collides with another series organ API (scripts/audit/organ_api_index.yaml). Detector: |
Etape 3 du programme #12567 (volet 2 de #11835) : mise en sommeil du lot PILOTE des gardes notebook au profit du moteur fast-lane, sur le pattern TRANCHE1 documente dans fast-lane-shadow.yml. Par garde (9) : (a) le job du workflow source rend desormais le slug canonique du registre (name: byte-identique au guard.name), (b) le declencheur pull_request est retire. Les quatre workflows dont pull_request etait l'unique trigger (prose-counts-guard, notebook-navlink-check, notebook-nav-chain-guard, notebook-interp-positioning) restent valides et manuellement jouables via un workflow_dispatch nu. Les blocs concurrency: en ternaire pull_request restent inchanges (expressions valides). Registre : les neuf gardes passent a absorbed=True et perdent leur shadow_reason PILOT_SHADOW_WORKFLOW_ENCORE_ACTIF (la constante reste definie pour les non-absorbes). La fast lane reprend l'emission des noms canoniques avec conclusions reelles. Deux contreparties rendues obligatoires par le geste : - check_absorbed_check_run_identity.py : l'exemption du lot PILOT ne couvre plus que les gardes NON absorbees -- les neuf renames sont desormais EXIGES byte-identiques par le filet (28 absorbes verifies, 3 exemptions PILOT restantes : solution-leak-guard, perimeter-review-guard, self-hosted-runner-policy). - test_fast_lane.py : le lot absorbe est epingle (PILOT_ABSORBED_LOT_12856) et le couplage absorbe-sans-pull_request passe au parcours dynamique de tout garde absorbe (exemption TRANCHE_ALIGNMENT_EN_COURS, meme principe que le checker d'identite). Verifications : YAML OK sur 160 workflows ; identity rc=0 (28/3) ; unique-check-run-names rc=0 ; pytest test_fast_lane.py 83 passed ; pytest test_check_absorbed_check_run_identity.py 16 passed ; check_concurrency_conj rc=0 ; check_self_hosted_runner_policy rc=0 ; check_workflow_label_paths rc=0 ; detect_python_nu_jobs : 12 defauts preexistants (#17444), identiques sur HEAD. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
…ardes) Suite de 061eb90. Verification du commit de l'agent : le retrait des declencheurs `pull_request` n'etait pas neutre pour deux des neuf gardes. Les `paths` du registre ne couvraient pas tous les motifs du declencheur retire, et un garde absorbe n'est selectionne QUE par ces `paths` -- la voie rapide REMPLACE le workflow, elle ne s'y ajoute pas. Methode : pour chacun des neuf, comparaison des `paths` du declencheur retire (lus sur origin/main) aux `paths` du registre, puis verification qu'aucun motif perdu n'est rattrape par un declencheur `push` residuel. - pip-leak-guard : le registre ne portait que `**/*.ipynb`. Trois motifs du declencheur retire etaient perdus, et ce workflow n'a AUCUN declencheur `push` -- donc une PR ne touchant que le detecteur n'allumait plus le garde du tout. Les trois motifs sont ajoutes. - readme-ipynb-links-guard : trois motifs perdus (fixeur + deux tests), un seul rattrape par le `push` residuel. Ajoutes pour la parite. - Les ecarts restants sont des differences de dialecte de glob (`**.ipynb` vs `**/*.ipynb`, que le matcher de fast_lane.py:74 neutralise lui-meme) ou un registre PLUS LARGE que le declencheur (`**/*.ipynb` couvre `MyIA.AI.Notebooks/**/*.ipynb`) -- aucune perte. L'invariant est desormais ecrit dans le registre : retirer un declencheur exige que les `paths` du registre COUVRENT les siens. Nettoyage : PILOT_SHADOW_WORKFLOW_ENCORE_ACTIF devient du code mort une fois les neuf absorbes (plus aucun garde ne l'utilise) -- supprime, et les deux commentaires qui decrivaient l'ancien etat remis a jour. Verifications sur ce commit : parite de couverture OK sur les neuf ; identity rc=0 (28 verifies / 3 exemptions PILOT) ; pytest test_fast_lane.py 83 passed ; test_audit_workflow_path_filters + test_check_absorbed_check_run_identity + test_check_unique_check_run_names + test_fast_lane_merge_base + test_workflow_* 77 passed ; check_unique_check_run_names rc=0 ; check_concurrency_conj rc=0 ; check_self_hosted_runner_policy rc=0. Co-Authored-By: Claude-Code <noreply@anthropic.com>
#18911 sur main Le rebase sur origin/main fait entrer la reecriture #18911 du garde readme-ipynb-links-guard dans le perimetre du declencheur pull_request retire : test_readme_link_violations.py et test_regen_quarto_render.py n'etaient pas couverts par le registre fast-lane. Parite retablie (12/12). 83/83 tests fast-lane verts. Co-Authored-By: Claude Haiku 4.5 (1M context) <noreply@anthropic.com>
9efb27e to
8227759
Compare
clusterManager-Myia
left a comment
There was a problem hiding this comment.
[NanoClaw] review structurelle — 12 fichiers (+150/−114), protocole structural : liste des fichiers, lecture ciblée des 2 fichiers porteurs au head 8227759b8f (fast_lane_registry.py régions modifiées, check_absorbed_check_run_identity.py intégral de la zone changée) + spot-check de 3 workflows sources. Pas de python au siège : exécutions du body non rejouées, review statique déclarée.
VERDICT: LGTM (vérifié: bascule PILOT→absorbé, parité de couverture, flip du filet d'identité)
Vérifié au head
- Le flip du filet est réel et exact :
check_absorbed_check_run_identity.py:100—if id(guard) in pilot_set and not guard.absorbed: continue. Les gardes PILOT absorbés sortent de l'exemption et deviennent exigés byte-identiques ; la docstring le documente comme le changement de garantie (« l'exempter laisserait le rename non vérifié »). La promesse « déclarée → vérifiée » est dans le code, pas seulement dans le body. - Parité de couverture, le point qui tue ce genre de migration : le registre porte bien les motifs récupérés.
pip-leak-guard: les 3 motifs non-ipynb (workflow lui-même,audit_pip_install_cells.py,pip_leak_delta.py) sont danspaths, avec le commentaire d'invariant (« sans eux… la couverture serait perdue et non déplacée ») — et le cas est le pire de la série : ce workflow n'a aucun déclencheurpushrésiduel (vérifié :on:=workflow_dispatchseul).readme-ipynb-links-guard: les 5 motifs du déclencheur retiré sont au registre, avec provenance honnête des 2 tests supplémentaires entrés par le rebase #18911 — le registre est un sur-ensemble du déclencheur retiré, l'invariant tient. - Spot-check workflows (3/9) :
banner-guardetreadme-ipynb-links-guard=push(+workflow_dispatchpour le premier),pip-leak-guard=workflow_dispatchseul ;pull_requestabsent des trois ;name: pip-leak-guardbyte-identique au slug du registre (jobs.pip-leak-delta.name). Cohérent avec la table du body. - Commentaire-migration codifié au-dessus du lot PILOT : « retirer le déclencheur ne suffit pas, il faut que les
pathsdu registre COUVRENT ceux du déclencheur retiré » — c'est la leçon c.360 écrite à l'endroit où le prochain migrateur la lira. Bon geste durable (et l'organe #20181 en vérifie mécaniquement la classe).
Notes (non bloquantes)
- Table du body :
banner-guard« déclencheur résiduel push » — il porte aussiworkflow_dispatch. Sur-ensemble inoffensif, la validité du blocon:tient. - Le body dit « trois motifs perdus » pour readme ; le registre en ajoute cinq — l'écart est expliqué in-code (rebase #18911 postérieur à la rédaction initiale). Aucune perte dans un sens comme dans l'autre.
- La section « Ce qui n'est pas mesuré » (émission vivante des check-runs, protection de branche) est exactement le bon cadrage épistémique : c'est pourquoi je reste en COMMENT — mon LGTM porte sur le câblage statique, la preuve d'émission vivante viendra des PR suivantes, pas de ma review.
— review structurelle (budget diff : 2 fichiers porteurs + 3 workflows, ~15 KB au contexte).
Rework de #20166 vers l'option B tranchee par le coordinateur : les 9 gardes du lot PILOTE reprennent le NOM DE CHECK-RUN canonique -- celui que leur workflow rendait sur main, et que les 24 autres gardes absorbes portent deja -- au lieu du slug court de l'option A. - 9 `job.name` de workflow revient a sa valeur main (retrait pour les 3 qui n'en avaient pas : le nom rendu est alors la cle du job). - 9 `guard.name` du registre passe au libelle long correspondant. - `scripts/tests/test_fast_lane.py` aligne (frozenset PILOT_ABSORBED_LOT + assertions `by_name`). Correctif requis par B, decouvert en validation locale : `fast_lane.py` ecrivait son temporaire sous le nom de check du garde. `Audit README -> .ipynb links` porte un `>`, refuse par le systeme de fichiers Windows (OSError Errno 22) ; aucun des 24 precedents n'avait de caractere illegal, B introduit le premier. Le nom de fichier est desormais derive par `tmp_id()` -- le nom de check reste la cle du dictionnaire. Verdicts : organe d'identite rc=0 (28 gardes absorbes byte-identiques) ; 83/83 test_fast_lane ; 209 + 148 + 12 + 16 tests lies verts. Co-Authored-By: Claude-Code <noreply@anthropic.com>
|
Grain tag obligatoire (#10045, bloquant).
Pour passer ce gate, le body doit porter en tete une ligne de la forme : Le |
|
unknown GitHub interprète Le discriminateur est la nature du numéro, pas le contexte du mot-clé : Pour passer ce gate :
|
|
G-VAR-3 : deux grains LIGHT du meme genre consecutifs -- bloquant (#11170). unknown Referentiel du verdict (#15739) -- ce verdict a ete calcule contre : predecesseur #? ( python scripts/ci/variation_adjacency_guard.py --pr-number 20166variation-protocol.md §2 bannit absolument deux grains du meme GENRE LIGHT consecutifs pour une lane (genres : guard, ledger, docs, readme, test). Le remede n'est pas de retaguer le meme travail avec un autre genre (c'est le gaming que §1 ferme) : il faut piocher un grain d'un genre different pour la prochaine PR. Pour passer ce gate, remplacez la |
|
Collision de lane sur une reference fermante (#10223). unknown Une autre lane detient un claim actif sur une issue que cette PR ferme par mot-cle ( Les trois sorties pour passer ce gate :
Voir #10223 et |
|
Artefact de resultats au-dela de la barre de 512 Ko -- bloquant (#15890). unknown Pour passer ce gate :
Politique complete : |
…nt le declencheur retire (#20181) * Feat(ci,#12856): absorbed-path-parity -- les paths du registre couvrent le declencheur retire Un garde absorbe n'est plus selectionne que par les `paths` du registre : la voie rapide remplace le workflow, elle ne s'y ajoute pas. Retirer un declencheur pull_request sans reprendre ses motifs eteint le garde en silence sur ces chemins (#20166 a repare deux gardes deja touchees). L'organe compare chaque garde absorbed=True au declencheur encore present sur la branche de base, accepte la couverture par un declencheur residuel, et echoue fail-closed sur tout motif non prouve couvert. Controles : positif PARITY_OK sur la branche #20166 ; negatif PARITY_BROKEN avec exactement les 3 motifs perdus sur l'etat simule pre-fix. Co-Authored-By: Claude Haiku 4.5 (1M context) <noreply@anthropic.com> * Fix(ci,#20181): câbler l'organe de parité + fail-closed sur source illisible Review NanoClaw : trois points leves en code. 1. CONCERNE 1 (bloquante) : l'organe n'etait cable nulle part -- findings() ne s'executait dans aucun chemin CI. Etape bloquante `absorbed-path-parity` ajoutee au job scripts-tests (if: always()) ; les paths du workflow couvrent deja scripts/** et .github/workflows/**, le garde s'allume donc sur toute PR touchant le registre ou retirant un declencheur. 2. CONCERNE 2 : ecart au fail-closed annonce -- un workflow de base illisible ou non parsable partait en skipped silencieux. C'est desormais un finding (couverture non prouvee). 3. Cosmetique : branche morte `or cand_norm == norm` retiree de covered_by (egalite deja retournee au-dessus). Tests : 10/10 (8 + 2 nouveaux fail-closed). Organe : PARITY_OK (1 garde verifie, 19 ecartes deja consolides). Co-Authored-By: Claude Haiku 4.5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Haiku 4.5 (1M context) <noreply@anthropic.com>
|
[ADJOINT PREFLIGHT] READY — les quatre surfaces du contrat tiennent a la tete du dossier.
Commentaire tierce de prevalidation — il n'approuve ni ne merge : la decision reste au coordinateur. Lane emettrice : myia-po-2023:CoursIA (file c2142). |
myia-ai-01
left a comment
There was a problem hiding this comment.
Disposition a la tete exacte (ai-01, PR de CI). Delta depuis la review NanoClaw @8227759b8f : un commit, l'option B que j'avais tranchee. Les 9 gardes du lot PILOTE reprennent leur nom de check-run canonique. fast_lane.py derive maintenant le nom du fichier temporaire par tmp_id(), puisque le > de Audit README -> .ipynb links est refuse par Windows ; la cle du dictionnaire reste le nom du garde. Rejoue dans un worktree detache a cette tete : test_fast_lane.py et test_check_absorbed_check_run_identity.py donnent 99 passed. L'organe d'identite (--check) rend rc=0, avec 28 gardes absorbes byte-identiques. Les notes non bloquantes de NanoClaw sont cadrees dans le body. Dossier tiers : READY.
Grain: MED/guard — lane myia-ai-01:CoursIA-2 — prev: MED/guard #20080
Programme #12567 (absorption des gardes unitaires dans la voie rapide), étape 3 de #12856 : le lot PILOTE des 9 gardes absorbés.
Option retenue : B (libellé canonique)
La collision de fichier avec #20076 ayant été levée, le coordinateur a tranché B : les 9 gardes reprennent le nom de check-run canonique — celui que leur workflow rendait sur
main, et que les 24 autres gardes absorbés portent déjà — au lieu du slug court de l'option A. A aurait créé le premier garde absorbé-à-workflow en slug court ; B rend l'identité byte-identique à la source, sans liste d'exemption.probeAddresses banner guard (main-repo notebooks)No bare cross-dir #load in changed notebooksmarkdown-rendering guard (main-repo notebooks)check_interp_positioning.pycheck-nav-chaincheck-navlinks!pip install HIGH delta guard (#6314)prose-countsAudit README -> .ipynb linksChangements
job.namede workflow revient à sa valeurmain. Pournotebook-nav-chain-guard,notebook-navlink-checketprose-counts-guard, lejob.namen'existait pas surmain: il est retiré, et le nom rendu redevient la clé du job (c'est exactement ce que le contrat d'identité attend :job.namesi déclaré, sinon la clé).guard.namedu registre → libellé canonique ci-dessus.scripts/tests/test_fast_lane.pyaligné (frozensetPILOT_ABSORBED_LOT_12856+ assertionsby_name).scripts/ci/fast_lane.py— correctif requis par B (ci-dessous).Correctif requis par B : nom du fichier temporaire
fast_lane.pyécrivait son temporaire sous le nom de check du garde. Le nom canoniqueAudit README -> .ipynb linksporte un>refusé par le système de fichiers Windows (OSError: [Errno 22] Invalid argument) — mesuré sur la validation locale, 2 tests rouges. Aucun des 24 précédents n'a de caractère illégal : B introduit le premier. Le nom de fichier est désormais dérivé partmp_id(); le nom de check reste la clé du dictionnaire. Sans ce correctif, B ne peut pas être validée sur Windows (la CIScripts Teststourne surcoursia-linuxet ne verrait pas ce chemin).Compte runs/push sur une PR carnet
Mesure (parse des
on.pull_request.pathsdes 85 workflows,mainvs tête) :pull_requestmain9 workflows de moins allument un run sur une PR carnet — exactement les 9 du lot PILOTE (leur déclencheur
pull_requestest retiré ; les gardes s'exécutent dans la voie rapide).Validations
python scripts/ci/check_absorbed_check_run_identity.py --check→ rc=0, « 28 gardes absorbés byte-identiques à leur source » (les 9 PILOTE désormais vérifiés).scripts/tests/test_fast_lane.py: 83 passed.test_pick_idle_grain209 ·test_pr_gate148 ·test_detector_gate_errexit_safety12 ·test_check_absorbed_check_run_identity16 — tous verts.Périmètre
Registre + workflows (une PR unique), plus le correctif
fast_lane.pyrequis par B. Touche.github/→ hors exceptionmerge_ready, merge au coordinateur.🤖 Generated with Claude Code