Skip to content

CONTROL #15998 (throwaway) — forced catalog-drift failure to observe PR gate classification - #16015

Closed
jsboige wants to merge 2 commits into
mainfrom
control/15998-advisory-gate
Closed

jsboige wants to merge 2 commits into
mainfrom
control/15998-advisory-gate

Conversation

@jsboige

@jsboige jsboige commented Sep 13, 2026

Copy link
Copy Markdown
Owner

Grain: MED/tooling — lane myia-po-2026:CoursIA — prev: LIGHT/qc #15946

Throwaway control PR — to be closed, never merged.

Positive control required by #15998 acceptance 4: force the catalog-drift job to
fail and observe how PR gate classifies it, so the advisory decision is a
measurement, not a declaration.

  • catalog-drift.yml carries the fix (job renamed with the advisory marker)
    plus an injected exit 1 step (CONTROL #15998 -- forced failure).
  • MyIA.AI.Notebooks/Probas/DecisionTheory/README.md gets an invisible HTML
    comment so the workflow's paths: filter matches and the job actually runs.

Expected on the fixed name: PR gate reports the failing check as advisory
(not in "failing checks"), whereas the pre-fix evidence quoted on the issue
showed PR gate: FAIL -- failing checks: Notebook catalog drift (read-only) (failure) on #15996.

🤖 Generated with Claude Code

jsboige and others added 2 commits September 13, 2026 20:14
`catalog-drift.yml` declared itself NON-BLOCKING twice in its own header, and
two docs already listed the check as advisory -- but pr_gate.py classifies
advisory by NAME (ADVISORY_MARKER, rule 6) and never reads
fast_lane_registry.py. Named "Notebook catalog drift (read-only)", the job
carried no marker, so any infrastructure failure (runner, pip install,
generate_catalog exit 2 on missing git metadata, cf #14831) was counted as a
REQUIRED check and reddened every notebook/README PR -- observed on #15996.

The issue proposed a fast_lane_registry entry with blocking=False. That is
inert for the gate (the registry is not consulted) and would additionally
absorb the catalog generation into the fast lane; the load-bearing surface is
the emitted check-run name. Fix accordingly:

- job renamed "Notebook catalog drift (read-only, advisory)" with a comment
  naming the contract and #15998;
- docs aligned on one truth: procedures-recurrentes.md claimed the red check
  was NON-mergeable (a bounce request), contradicting catalog-pr-hygiene.md and
  ci-aggregator-rollout.md -- now advisory everywhere, new check name in the
  aggregator table;
- regression guard in test_pr_gate.py: asserts the job name carries the marker
  (robust to renames that keep it) and that the historical spelling stays
  classified blocking, so the defect stays measurable.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…ailure

Injected forced failure + README trigger to observe how PR gate classifies the
catalog-drift check on the fixed name. Throwaway: PR closed after observation.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
@jsboige

jsboige commented Sep 13, 2026

Copy link
Copy Markdown
Owner Author

Contrôle terminé — verdict mesuré et collé sur #15998. PR jetable fermée, branche supprimée (le correctif vit dans #16016).

@jsboige jsboige closed this Sep 13, 2026
@jsboige
jsboige deleted the control/15998-advisory-gate branch September 13, 2026 18:36
myia-ai-01 pushed a commit that referenced this pull request Sep 16, 2026
…and the docs now say so (#16016)

* fix(ci,#15998): make the catalog-drift check advisory for the gate

`catalog-drift.yml` declared itself NON-BLOCKING twice in its own header, and
two docs already listed the check as advisory -- but pr_gate.py classifies
advisory by NAME (ADVISORY_MARKER, rule 6) and never reads
fast_lane_registry.py. Named "Notebook catalog drift (read-only)", the job
carried no marker, so any infrastructure failure (runner, pip install,
generate_catalog exit 2 on missing git metadata, cf #14831) was counted as a
REQUIRED check and reddened every notebook/README PR -- observed on #15996.

The issue proposed a fast_lane_registry entry with blocking=False. That is
inert for the gate (the registry is not consulted) and would additionally
absorb the catalog generation into the fast lane; the load-bearing surface is
the emitted check-run name. Fix accordingly:

- job renamed "Notebook catalog drift (read-only, advisory)" with a comment
  naming the contract and #15998;
- docs aligned on one truth: procedures-recurrentes.md claimed the red check
  was NON-mergeable (a bounce request), contradicting catalog-pr-hygiene.md and
  ci-aggregator-rollout.md -- now advisory everywhere, new check name in the
  aggregator table;
- regression guard in test_pr_gate.py: asserts the job name carries the marker
  (robust to renames that keep it) and that the historical spelling stays
  classified blocking, so the defect stays measurable.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* docs(tooling,#15998): the one-shot catalog-drift repair no longer unblocks a PR

Its docstring sold it as unblocking UNSTABLE PRs -- true while PR gate counted
the catalog-drift check as required. With the check advisory (#15998) a drift
blocks nothing, so the premise is stated for what it is (a local repair of a
non-deterministic Counter.most_common() tie-break) instead of a claim the CI no
longer honours. Behaviour unchanged.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* docs(catalog,#16016): catalog_markers.md cesse de promettre un blocage qui n'existe plus

Repare le defaut frais signale par ai-01 (DM 2026-09-15T10:23Z) : la section
"CI Integration" de docs/reference/catalog_markers.md affirmait encore
"If either check fails, the PR is blocked until markers are updated" (l.108),
contraire au routage advisory installe par cette PR (#15998).

En le verifiant firsthand, le defaut etait plus large que la seule phrase citee :

- le workflow n'utilise PAS `expand_catalog_markers.py --check` (aucun `--check`
  dans .github/workflows/catalog-drift.yml) : il REGENERE puis compare par un
  unique `git diff --cached` ;
- `verify_catalog_readme.py` n'est appele par AUCUN workflow (present seulement
  dans scripts/notebook_tools/README.md et ses propres tests) : la "seconde
  verification" decrite n'existe pas ;
- le job est toujours vert (drift remonte en annotation `notice` uniquement).

La description des "deux checks en sequence" est donc remplacee par le mecanisme
reel, + le contrat de nom (`advisory` dans le NOM du job, classe par pr_gate.py
regle 6), + la raison (une panne d'infra ne doit pas bloquer une PR), + un
encadre de correction factuelle date.

Prose FR (convention docs/ FR-first, cf .claude/rules/readme-french-first.md).

Tests cibles sur current-main (branche a 0 en retard apres fusion deliberee) :
- scripts/tests/test_pr_gate.py : 128 passed
- scripts/tests/test_check_unique_check_run_names.py : 13 passed
- scripts/ci/check_unique_check_run_names.py : 84 jobs / 64 workflows, 0 doublon
- nom du job conserve `advisory` apres fusion (verifie l.53)

Grain: LIGHT/doc-consistency -- lane myia-po-2026:CoursIA -- prev: P0/repair #15991
See #16016

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

* docs(#16016): corriger 3 contradictions catalog_markers.md — peut rougir (pas toujours vert), paths filter, --check local

(1) « Le job est toujours vert » remplace par le contrat reel : seul rc=2 (metadonnees git
indisponibles) est absorbe en notice ; tout autre echec rend le job rouge, rouge exclu des
causes bloquantes par PR gate via le marqueur advisory (controle positif #16015) ;
(2) introduction : « verified by CI on every PR » harmonise avec le filtre paths: du workflow ;
(3) Script Usage : « used by CI » retire de expand_catalog_markers.py --check (le workflow
regenere, il n'appelle jamais --check).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant