Repository navigation
fix(ci,#11835): une panne de la voie ombre ne retient plus une PR saine (2e mecanisme) - #12873
Conversation
Second mecanisme de blocage par la phase ombre, distinct de celui ferme par #12868. Celui-la ne passe pas par les check-runs mais par le CODE DE RETOUR du job. Quand l'arbre n'est pas revenu a son etat apres la bascule base/HEAD, la voie ombre refuse de publier des verdicts -- c'est correct, ils porteraient sur un arbre dont on ne sait plus ce qu'il contient. Mais elle le faisait par `raise SystemExit(...)`, donc exit 1. Or le check du job s'appelle `Fast lane (ombre) -- N gardes, 1 checkout`, qui ne contient pas `advisory` : `pr_gate` le compte comme un defaut et BLOQUE la PR. Une panne de la voie ombre bloquait donc une PR saine -- exactement ce que la phase pilote promet de ne pas faire. Mesure : #12820 etait retenue par ce seul chemin (run 32774643069, 45 checks verts, aucun defaut propre), en plus de son `PR gate` perime. Correctif : en mode ombre, imprimer le diagnostic sur stderr et rendre 0. Le fail-closed est PRESERVE dans les deux modes -- aucun verdict n'est publie. Hors ombre, l'arret net est inchange. Tests, deux moities et un controle positif : - l'ombre rend 0 ET ne publie rien (un test qui ne verifierait que le code de retour laisserait passer un correctif publiant des verdicts faux) ; - hors ombre, `SystemExit` est toujours levee -- sans quoi un correctif rendant 0 dans les deux modes desarmerait la voie rapide le jour de sa bascule, en passant pour un deblocage. Les deux tests sont verifies par MUTATION : retirer le court-circuit ombre, puis le faire publier quand meme, font rougir le test dans les deux cas. Un test qui n'atteindrait pas le chemin passerait vert tout aussi bien. python -m pytest scripts/tests/test_fast_lane.py -q -> 41 passed Grain: MED/guard - lane myia-ai-01:CoursIA - prev: MED/guard #12868 See #11835 Co-Authored-By: Claude-Code <noreply@anthropic.com>
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 |
github-actions
Bot
added
the
variation-light-cap-reached
|
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. 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 variation-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 |
|
G-VAR-2 light cap reached (advisory, non bloquant). |
1 participant
Grain: MED/guard - lane myia-ai-01:CoursIA - prev: MED/guard #12868
Le second mecanisme
#12868 a ferme le blocage par check-run (
failurepublie sous un nom sansadvisory). Celui-ci est distinct : il passe par le code de retour du job.Quand l'arbre n'est pas revenu a son etat apres la bascule base/HEAD, la voie
ombre refuse de publier des verdicts. C'est correct -- ils porteraient sur
un arbre dont on ne sait plus ce qu'il contient. Mais elle le faisait par
raise SystemExit(...), donc exit 1. Le check du job s'appelleFast lane (ombre) -- N gardes, 1 checkout: il ne contient pasadvisory,donc
pr_gatele compte comme un defaut et bloque la PR.Une panne de la voie ombre retenait donc une PR saine.
Mesure
#12820, run
32774643069:45 checks verts, aucun defaut propre a la PR. Elle etait retenue par la
panne de l'observateur.
Correctif
En ombre : diagnostic sur stderr,
return 0. Le fail-closed est preservedans les deux modes -- aucun verdict n'est publie sur un arbre inconnu.
Hors ombre, l'arret net est inchange.
Tests -- deux moities, un controle positif, et une verification par mutation
Deux moities, parce qu'un test qui ne verifierait que le code de retour
laisserait passer un correctif publiant des verdicts faux en silence :
0etpublished == [];SystemExitest toujours levee. Sans lui,un correctif rendant 0 dans les deux modes desarmerait la voie rapide le
jour de sa bascule, tout en passant pour un deblocage.
Et parce qu'un test qui n'atteint pas le chemin passe vert exactement comme un
test qui le couvre, les deux sont verifies par mutation :
if args.shadow->if False)return 0mais publier quand meme les verdictsLe test porte aussi une assertion sur le registre : si plus aucun garde n'a de
delta_argv, il echoue en disant qu'il n'exerce plus rien -- plutot que dedevenir vert par vacuite.
Portee
Ne touche ni la parite de declencheurs (P1) ni la bascule elle-meme : cette PR
retire a la voie ombre sa capacite a bloquer, y compris quand elle tombe en
panne. Elle ne lui retire pas sa capacite a signaler -- le diagnostic reste
imprime, et l'absence de verdicts reste visible sur la PR.
Adjacence de genre, declaree
prev: MED/guard #12868-- deuxguardconsecutifs sur ma lane. Substancesdistinctes (conclusion de check-run vs code de retour du job), diagnostiquees
chacune depuis un log de run precis : le litmus LIGHT ne s'applique pas, on
n'en genere pas une douzaine en scannant l'instance suivante. Je le declare
plutot que de le maquiller en deux genres.
See #11835