Skip to content

Make check a required status check on master — every CI gate is currently advisory #1547

Description

@bloknayrb

What is true today

master has no branch protection ("protected": false). No status check is required, so a red check job does not block a merge — CI is a visible signal on the PR page, not a gate.

That applies to every check in ci.yml: check (biome + typecheck + the full vitest suite), all three rust-test legs, reaper-build, and CodeQL. Any of them can be red at the moment a PR is merged.

Why it is being filed now

#1399 wires the acceptance harness into the check job so it stops being a thing only a hand-run executes. That is worth doing regardless — a visible red signal is the difference between #1397's outcome and no outcome. But "wired into CI" reads as a stronger guarantee than it delivers while nothing requires the check to be green.

#1399 deliberately does not assert the current setting in a tracked file. An auto-loaded file claiming "master is unprotected" would be wrong the day the setting flips, and CLAUDE.md's own rule is that a criterion must be answerable from tracked files. So it ships a durable conditional instead:

A red check blocks a merge only where check is a required status check — that is a repo setting, not a file, so confirm it before treating this as a merge gate.

That conditional is correct forever, but it never discharges. Without this issue it is a permanent tax on every future reader, who has to go and check the setting themselves each time. This issue is the thing that can close it.

The ask

A repo-settings change only you can make: enable branch protection on master and mark check (at minimum) as a required status check.

Worth deciding at the same time:

  • Which checks are required. check is the obvious one. The three rust-test legs are the next candidates — the sweep that produced this issue found several changes whose only real gate was a platform-specific CI leg, because a #[cfg(target_os = …)] body is parsed but not type-checked on a non-matching host.
  • Whether to require branches be up to date before merging. This costs a rebase on every stale PR; it buys protection against two PRs that pass independently and break together.
  • Whether you want to be able to bypass it. As the sole maintainer, an admin bypass is reasonable; the value here is the default, not the enforcement.

Not blocking anything

#1399 is correct and mergeable as it stands. This is the follow-up that makes its hedge unnecessary.

Note

Filed from an automated open-issue sweep, surfaced by an adversarial review of #1399. Not a user report.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions