Skip to content

fix(branch-protection): narrow jackin required check to docs-link-check#12

Merged
donbeave merged 1 commit into
mainfrom
fix/required-checks-narrow-to-docs-link-check
Apr 25, 2026
Merged

fix(branch-protection): narrow jackin required check to docs-link-check#12
donbeave merged 1 commit into
mainfrom
fix/required-checks-narrow-to-docs-link-check

Conversation

@donbeave

Copy link
Copy Markdown
Member

Summary

Replace the dual-context list `["build", "docs-link-check"]` from #11 with `["docs-link-check"]` only.

Why #11 didn't work

#11 was based on a wrong assumption: that `required_status_checks` accepts an OR-list ("any one must pass"). It's actually AND-semantics — every entry has to pass. So after #11 applied:

A PR's branch only carries one or the other name, so AND-semantics makes the dual-context rule unsatisfiable. `--admin` doesn't help either — the ruleset has `current_user_can_bypass: never` and no `bypass_actors` configured (intentional strict enforcement).

Approach — narrow, then natural cascade

Drop `"build"` and keep only `"docs-link-check"`. After this applies:

  1. #181 unblocks immediately — it already has `Docs / docs-link-check` green from CI.
  2. Merge #181 — `main` now has the renamed job committed; every future push produces `docs-link-check`.
  3. Sync #180 with main — rebase or merge `main` into the PR branch so its CI run produces `docs-link-check` too.
  4. Merge #180.

No admin override, no enforcement window where the rule is off, no `bypass_actors` weakening. The rule simply hops to its target context and PRs naturally adapt on rebase.

Apply plan to expect

```
~ resource "github_repository_ruleset" "protect_main" {
~ rules {
~ required_status_checks {
- required_check { context = "build" }
- required_check { context = "docs-link-check" }
+ required_check { context = "docs-link-check" }
}
}
}
Plan: 0 to add, 1 to change, 0 to destroy.
```

(The diff might show both `docs-link-check` entries because Terraform recreates the set; the net effect is one entry remaining.)

Test plan

🤖 Generated with Claude Code

Replace the dual-context list ["build", "docs-link-check"] from #11
with ["docs-link-check"] only.

The dual-context attempt was based on a wrong assumption that the
required_status_checks list is OR-semantics (any one must pass). It's
AND-semantics (every entry must pass). After #11 applied:

- jackin-project/jackin#180 has Docs/build green, no docs-link-check
  check on its branch -> blocked, missing docs-link-check.
- jackin-project/jackin#181 (the rename PR) has Docs/docs-link-check
  green, no build check on its branch -> blocked, missing build.

Each PR can only ever produce one of the two names, so AND-semantics
makes the rule unsatisfiable.

The fix: drop the legacy "build" context, since the rename PR (#181)
will produce only "docs-link-check" once merged. Apply order:

1. Apply this PR.
2. #181 unblocks (it has docs-link-check green) -> merge it. Main
   now produces docs-link-check on every push.
3. Sync #180 with main (rebase or merge from main into the PR branch)
   so its CI run also produces docs-link-check -> #180 unblocks ->
   merge it.

No admin override, no enforcement-disabled window, no bypass_actors
weakening. The rule simply hops to its target context and existing
PRs adapt naturally on rebase.

Verified locally:
- `tofu fmt -check` clean
- `tofu validate` clean (pre-existing vulnerability_alerts deprecation
  warning unrelated)
- Pre-commit secret scan clean

Co-authored-by: Claude <noreply@anthropic.com>
Signed-off-by: Alexey Zhokhov <alexey@zhokhov.com>
@sonarqubecloud

Copy link
Copy Markdown

@donbeave donbeave merged commit f60123b into main Apr 25, 2026
2 checks passed
@donbeave donbeave deleted the fix/required-checks-narrow-to-docs-link-check branch April 25, 2026 22:29
donbeave added a commit that referenced this pull request May 7, 2026
…ck (#12)

Replace the dual-context list ["build", "docs-link-check"] from #11
with ["docs-link-check"] only.

The dual-context attempt was based on a wrong assumption that the
required_status_checks list is OR-semantics (any one must pass). It's
AND-semantics (every entry must pass). After #11 applied:

- jackin-project/jackin#180 has Docs/build green, no docs-link-check
  check on its branch -> blocked, missing docs-link-check.
- jackin-project/jackin#181 (the rename PR) has Docs/docs-link-check
  green, no build check on its branch -> blocked, missing build.

Each PR can only ever produce one of the two names, so AND-semantics
makes the rule unsatisfiable.

The fix: drop the legacy "build" context, since the rename PR (#181)
will produce only "docs-link-check" once merged. Apply order:

1. Apply this PR.
2. #181 unblocks (it has docs-link-check green) -> merge it. Main
   now produces docs-link-check on every push.
3. Sync #180 with main (rebase or merge from main into the PR branch)
   so its CI run also produces docs-link-check -> #180 unblocks ->
   merge it.

No admin override, no enforcement-disabled window, no bypass_actors
weakening. The rule simply hops to its target context and existing
PRs adapt naturally on rebase.

Verified locally:
- `tofu fmt -check` clean
- `tofu validate` clean (pre-existing vulnerability_alerts deprecation
  warning unrelated)
- Pre-commit secret scan clean

Signed-off-by: Alexey Zhokhov <alexey@zhokhov.com>
Co-authored-by: Claude <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