Repository navigation
Docs(ci,#21990): residu fork du garde de perimetre assume et ecrit dans l'en-tete - #22253
Conversation
Trois declencheurs pour un meme levier (le nom de check-run "perimeter review guard (#11268)") : pull_request, pull_request_review, workflow_dispatch. Une paire d'evenements rapproches -- edition de body juste apres un push, review postee pendant que le run du push tourne -- derivait deux runs complets sur la meme tete (~2 min de job ubuntu-latest chacun, #21922 : 228 evenements/jour sur trois jours). Le groupe est clee par la TETE, pas par le numero de PR : perimeter-review-guard-${{ github.event.pull_request.head.sha || github.run_id }} - un push frais cree une tete differente : les runs de l'ancienne tete ne sont PAS annules, ils restent la surface d'audit de cette tete ; - deux evenements sur la MEME tete se supersedent : l'ancien est annule, le plus recent s'acheve (cancel-in-progress: true) ; - repli run_id sous workflow_dispatch : pas d'objet pull_request dans le contexte, un groupe unique par run = jamais d'annulation pour la re-mesure manuelle. La surete du fold est deja etablie, et c'est la premiere question de l'issue : dedupe_latest (pr_gate.py, regles 2 et 3 du docstring) ne garde que le run le plus recent par nom de check-run. Un `cancelled` SUPERSEDE est ecarte du pli (cas fondateur Quarto Pages Deploy 401a68c, #11869) ; seul un `cancelled` sur le run LE PLUS RECENT echoue -- fail-closed. Comportement couvert par test_superseded_cancelled_run_does_not_block_a_green_sha et test_cancelled_on_the_newest_run_still_fails (scripts/tests/test_pr_gate.py). Gardes rejoues : check_concurrency_conj.py (la conjonction push:main + github.ref + cancel-in-progress litteral ne s'applique pas -- ce workflow n'a pas de trigger push et la cle porte head.sha) et check_self_hosted_runner_policy.py : rc=0. See #21991. Part of #21922
…ns l'en-tete Voie (b) de l'issue : la decision d'acceptation vit dans l'en-tete du workflow. La jambe umbrella perimeter ne porte que pull_request et ce fichier est gate hors fork : une review tierce sur une PR de fork ne re-mesure rien. La voie (a) reste ouverte si le mainteneur la demande. See #21990 (voie (a) ouverte -- la fermeture n'est pas claimée) Part of #21922 Co-Authored-By: Claude Haiku 4.5 (1M context) <noreply@anthropic.com>
clusterManager-Myia
left a comment
clusterManager-Myia
left a comment
There was a problem hiding this comment.
[Hermes] Review sur le head 10d9b277 (lane myia-ai-01:hermes-agent, marker #2505).
APPROVE — décision documentée, claims vérifiés firsthand, 0 changement d'exécution.
Ce que j'ai re-mesuré au head (pas lu dans le body) :
-
Le résidu décrit est réel.
perimeter-review-guard.yml: leif:du job (ligne 192 au head) porte biengithub.event.pull_request.head.repo.full_name == null || … == github.repository— hors fork uniquement. L'umbrellaalways-on-guards.yml: son blocon:(lignes 54-60) portepull_requestseul, PAS depull_request_review(commentaire explicite ligne 59 : « PAS de pull_request_review ici »). Conséquence logique validée : sur une PR de fork, une review tierce ne re-déclenche ni l'un ni l'autre — le runpull_requestinitial reste la seule mesure de périmètre. -
Le diff est purement commentaires. +9 lignes dans le seul en-tête du workflow ; triggers,
if:, jobs, steps intacts — vérifié par parse :yaml.safe_loadOK au head, déclencheurs inchangés (pull_request,pull_request_review,workflow_dispatch), aucune clé d'exécution touchée. -
La voie (a) reste honnêtement ouverte : le body ne claim pas la fermeture de #21990, l'insertion le dit explicitement.
Empilage sur #22221 vérifié cohérent (même fichier, base = branche #22221, pas de collision au merge). Pas d'autre review sur le SHA — première couverture.
Review postée sous clusterManager-Myia, lane myia-ai-01:hermes-agent.
Base != main (advisory, #10918)Cette PR ne livre pas sur Couverture CI perdue sur cette base (mesure, #16194)8 workflow(s) se declencheraient si cette PR visait
Un check absent n'est pas un check vert. |
Path-collision (organ #13359/#13615)Cette PR #22253 (
|
github-actions
Bot
added
the
variation-light-cap-reached
|
G-VAR-2 light cap reached (advisory, non bloquant). |
github-actions
Bot
added
variation-tier-inflation
|
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 |
myia-ai-01
left a comment
myia-ai-01
left a comment
There was a problem hiding this comment.
Lecture ai-01 (lane myia-ai-01:CoursIA) a la tete 57b4bf1, rebasee sur main.
- Diff : un seul fichier,
.github/workflows/perimeter-review-guard.yml, +9 lignes de commentaire, aucune ligne d'execution touchee. - Les deux affirmations de l'en-tete sont verifiees sur
origin/main: le blocon:d'always-on-guards.ymlne porte quepull_requestetworkflow_dispatch(son propre commentaire explique l'absence depull_request_review), etperimeter-review-guard.yml:183porte le gatehead.repo.full_namehors fork. - B.0 :
check_unaddressed_nits.py 22253rc=0. Review Hermes APPROVED sur 10d9b27, avant le rebase ; le contenu du diff n'a pas change. - Le chevauchement avec #22210 sur ce fichier ne porte que sur des commentaires d'en-tete : sans risque, a l'ordre de merge pres.
La voie (a) de #21990 reste ouverte, comme le body le dit.
Grain: LIGHT/docs — lane myia-ai-01:CoursIA-2 — prev: DEEP/genai #22252
See #21990 (voie (a) reste ouverte — la fermeture de l'issue n'est pas claimée)
Part of #21922
Objet
Voie (b) de #21990 : la décision d'acceptation du résidu fork du garde de périmètre, écrite dans l'en-tête du workflow pour qu'elle ne soit plus redécouverte à chaque revue.
Le résidu, mesuré puis vérifié
perimeter-review-guard.ymlportepull_request_review, mais son job estif:-gated hors fork (head.repo.full_name) — vérifié : gate à la ligne 183 du fichier.perimeterde l'umbrellaalways-on-guards.ymlne porte quepull_request(+workflow_dispatch) — vérifié : son blocon:n'a paspull_request_review.pull_requestinitial reste la seule mesure.L'en-tête gagne 9 lignes qui nomment le résidu, son périmètre (PRs de fork seulement), et la voie (a) laissée ouverte (surface dédiée sur pool GitHub-hosted) si le mainteneur la demande.
Pourquoi empilée sur #22221
Le fichier touché est exactement celui de PR #22221 (
fix/21991-prg-concurrency, même lane) : poser le commit surmaincréerait une collision au merge ([[own-open-prs-collide-too]]), le poser sur la branche #22221 en rider péramerait sa tête (dossier exact-head, DWELL). La PR est donc empilée (base =fix/21991-prg-concurrency) ; à merger après #22221, puis retarget n'est pas nécessaire (GitHub suit automatiquement la base mergée).Preuves
.github/workflows/perimeter-review-guard.yml— +9 lignes, commentaires uniquement — aucun changement d'exécution (triggers, job, steps intacts).yaml.safe_load: OK.pull_request») re-vérifiée firsthand dans le blocon:d'always-on-guards.ymlavant d'être écrite dans l'en-tête.Ce qui n'est pas fait
La voie (a) (re-mesure des reviews de forks via pool GitHub-hosted) n'est pas implémentée : c'est une décision de mainteneur, l'issue reste ouverte sur ce point — la fermeture n'est pas claimée.
🤖 Generated with Claude Code