feat(tofu): drop gate from required checks (ADR-0001 step 3, closes #35) - #65
Conversation
DO NOT MERGE BEFORE 2026-05-22. Held draft PR per ADR-0001 *Rollout status* step 3: drop `gate` from the management-repo required-status-check set once the one-week observation window for the additive step 2 (PR #52, merged 2026-05-15) passes cleanly. `gate-verified` (with the post-#62 two-check shape: gate-conclusion + workflow-content blob-compare + label exception) subsumes every case the standalone `gate` required check caught: - PR removes `gate` job from tofu-plan.yml — gate-verified check 1 sees no `gate` in jobs list, reports `failure`. - PR renames the `gate` job — same: no match, `failure`. - PR makes `gate` skip/cancel/fail — gate-verified check 1's `conclusion == "success"` assertion fails. - PR keeps `gate` but stubs its body to `exit 0` — gate-verified check 2 detects the tofu-plan.yml modification; without the `workflow-update` label, fails. With the label, intentional maintainer exception (residual bounded). In-workflow `gate` job stays in tofu-plan.yml because gate-verified check 1 reads its conclusion. Only its required-check status at the ruleset level changes. Inline comment block above the `required_check` list rewritten to describe gate-verified's two-check behavior and the role of the in-workflow `gate` job post-step-3. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
module.ruleset_tag_protection.github_organization_ruleset.tag_protection: Refreshing state... [id=16260826] OpenTofu used the selected providers to generate the following execution OpenTofu will perform the following actions: github_repository_ruleset.management_repo_checks will be updated in-place~ resource "github_repository_ruleset" "management_repo_checks" { Plan: 0 to add, 1 to change, 0 to destroy. ───────────────────────────────────────────────────────────────────────────── Note: You didn't use the -out option to save this plan, so OpenTofu can't |
Observation-window attribution complete (2026-05-19)The "Step-2 observation window … closed cleanly" checkbox can be honestly evaluated. Per #66 attribution (now closed):
Net: zero false positives, zero false negatives. ADR-0001 step 2's acceptance criterion is satisfied. Remaining pre-merge work for this PR: keep observing through 2026-05-22 (calendar gate), rebase if anything lands, then promote out of draft + merge. |
Review summary (/review-pr + adversarial review)Verdict: SAFE-TO-MERGE. Preconditions met, both operational blockers cleared. Security claim — could not be refutedDropping Preconditions
Blockers cleared
No code defect. Adversarial review performed by an independent agent (Codex quota was exhausted; ran on Opus instead). |
ADR-0007 generalized unifi-mcp's six required checks to all six org repos. Measured per repo instead: only unifi-mcp and unraid-mcp have that set, gandi-mcp and flipperzero-mcp and shortcut-mcp each have their own, protonmail-mcp gates on a single `test`, and `.github` has none at all. Since automerge inherits whatever gate a repo has, the ADR now carries the real table and names which repos are eligible. `.github` gets its own consequence: it has no required check and now has the auto-merge capability, and it holds the preset every other repo extends. CLAUDE.md still described `gate` as a required check in four places. PR #65 dropped it (ADR-0001 step 3, issue #35); the live ruleset requires gate-verified, zizmor, gitleaks, actionlint, analyze (actions). `gate` still runs as a job. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This PR is held in draft pending the ADR-0001 step 2 observation window (PR #52 merged 2026-05-15; one full week → ≥2026-05-22). When the window closes cleanly, mark this ready and merge.
Summary
Removes `required_check { context = "gate" }` from `github_repository_ruleset.management_repo_checks` in `repos_meta.tf`. `gate-verified` becomes the sole required check sourced from the `tofu` workflow path.
The in-workflow `gate` job stays in `tofu-plan.yml` because `gate-verified` check 1 reads its conclusion via `select(.name == "gate") | .conclusion`. This PR only changes whether `gate` itself is required at the ruleset level.
Why this is safe
`gate-verified` (with the post-#62 two-check shape) subsumes every case the standalone `gate` required check caught:
ADR-0001 Rollout status step 3 line: "Drop is safe because everything `gate` catches on its own (failure or non-skip non-success) is already caught by `gate-verified`'s `conclusion == "success"` assertion." Plus check 2 now covers the stub-with-success residual originally noted there.
What the inline comment now describes
The comment block above the `required_check` list is rewritten to describe gate-verified's two checks + the role of the in-workflow `gate` job (still load-bearing as the source signal). Reads top-to-bottom for a new contributor.
Test plan
Pre-merge
Post-merge
Adversarial (optional, separate canary)
The acceptance criteria in #35 mentions an adversarial test where a PR renames the `gate` job and gate-verified blocks the merge. Canary #57 already empirically verified the deletion case (`mergeStateStatus: BLOCKED`, both required checks absent). Rename is functionally identical from gate-verified's perspective (`select(.name == "gate") | empty → "missing"`); a fresh rename canary is redundant but can be done if extra confidence is wanted.
Closes #35.
🤖 Generated with Claude Code