Skip to content

fix(inventory): arm the public repos' promotion branches (backend#1681) - #250

Open
LukasWodka wants to merge 1 commit into
developfrom
fix/1681-arm-public-promotion-checks
Open

fix(inventory): arm the public repos' promotion branches (backend#1681)#250
LukasWodka wants to merge 1 commit into
developfrom
fix/1681-arm-public-promotion-checks

Conversation

@LukasWodka

@LukasWodka LukasWodka commented Aug 13, 2026

Copy link
Copy Markdown
Contributor

Closes one of the documented divergences carried by backend#1681, and part of epic backend#1680.

The gap

model-zoo, start-training and docs required no content gates on either promotion branch. All three are public repos.

branch required checks before after
docs/main none at all gate / gate, quality / gitleaks, quality / house-rules
docs/staging none at all same
model-zoo/main ruff, 4 test jobs, gate / gate + gitleaks, house-rules
model-zoo/staging gate / gate + gitleaks, house-rules
start-training/main gate / gate + gitleaks, house-rules
start-training/staging gate / gate + gitleaks, house-rules

quality / gitleaks was required on all three develops and on none of their six promotion branches. A credential reaching develop was scanned; the same content arriving on a public prod branch was not.

The branches were armed via the API first; this file follows so the guard's contract matches reality.

Why arming was safe, checked rather than assumed

  • The contexts report on these PRs. Each repo's code-quality-caller.yml triggers on pull_request with no branch filter, and docs' fr-gate-caller.yml names branches: [staging, main, master]. A required check that can never report bricks the branch permanently — this org has already hit that with pii-gate/pii-check and client#665.
  • Armed while green. All three were measured green beforehand, including on real release-train/to-main promotion PRs (start-training, 2026-08-12 15:55).
  • soft-fail: false was armed on all three on 2026-08-11, so these checks can genuinely fail.

What is deliberately NOT changed

docs keeps min_reviews: 0. The 2026-06-04 exemption is about review, and it stands. Its shared reason already claimed the divergence "names min_reviews alone" — that sentence was false while required_checks: [] sat beside it, and is true now.

The docs protection PUT restated every other setting (enforce_admins, required_conversation_resolution, force-push/deletion blocks, required_pull_request_reviews: null); a full-object diff before/after confirms only required_status_checks moved, on all six branches.

Verification

  • caller-drift-selftest.py162/162 pass
  • Live audit with this inventory — exit 0, 19/19 repos read, 0 findings
  • Mutation: added an unrequired context to protection_policy.prod.required_checks; the anchor applied (canary present in the parsed file) and the audit went to exit 1 with 16 findings, all three of these repos among them — including docs, proving its divergent cell now evaluates required_checks instead of overriding it away. Reverted; 0 canary lines remain.

Still open on backend#1681

quality / action-pins is required on 16/16 develops and 1/16 prod branches (only .github). That asymmetry is still unexplained rather than decided, and this PR does not bless it either way.


Note

Low Risk
Inventory-only documentation aligned with live GitHub protection; no application or workflow logic changes in this diff.

Overview
Updates repo-inventory.yml so the caller-drift contract matches branch protection already armed on three public train repos (docs, model-zoo, start-training).

For model-zoo and start-training, staging and prod drop documented divergent blocks that only required gate / gate and now use plain required, so the fleet baseline applies: gate / gate, quality / gitleaks, and quality / house-rules.

For docs, staging and prod keep divergent with min_reviews: 0 (review exemption unchanged) but remove required_checks: [], so those branches are no longer documented as requiring no status checks and inherit the same fleet baseline as the other train repos.

Comments record the 2026-08-13 closure of backend#1681 and that docs' shared reason about naming min_reviews alone is accurate again now that empty required_checks is gone.

Reviewed by Cursor Bugbot for commit 0bef0a5. Bugbot is set up for automated code reviews on this repo. Configure here.

model-zoo, start-training and docs required no content gates on staging or
prod. All three are PUBLIC. Measured 2026-08-13:

  docs/main, docs/staging        no required status checks AT ALL
  model-zoo/{main,staging}       gate / gate only, no gitleaks, no house-rules
  start-training/{main,staging}  gate / gate only, no gitleaks, no house-rules

`quality / gitleaks` was required on all three develops and on none of their
six promotion branches, so a credential reaching develop was scanned and the
same content arriving on a public prod branch was not.

Armed to the fleet baseline on all six roles, then this file follows. Safe to
arm because each repo's code-quality caller triggers on `pull_request` with no
branch filter (docs' fr-gate caller names staging/main/master explicitly), so
every context reports on promotion PRs -- a required check that never reports
bricks the branch, which is the failure this org has already had twice. And
all three were measured green first, including on release-train/to-main PRs.

docs keeps `min_reviews: 0` -- the 2026-06-04 content-only exemption is about
REVIEW and is untouched. Its shared reason already claimed the divergence
"names `min_reviews` alone"; that was false while `required_checks: []` sat
beside it, and is true now.

Verified: selftest 162/162; a live audit with this inventory exits 0 across
19 repos; and under a mutation adding an unrequired context to the prod policy
floor, all three repos go red -- so these cells evaluate rather than pass by
being unasserted.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@LukasWodka LukasWodka self-assigned this Aug 13, 2026
@LukasWodka
LukasWodka requested review from saadqbal and shujaatTracebloc and removed request for saadqbal August 13, 2026 22:50
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