Enforce Required Status Checks with Codeac Branch Protection Rules

The problem: merges landing while the validating pipeline is red

A pull request can look finished — approvals in place, diff reviewed — while the CI job that actually validates it is still failing or never ran. Without a merge gate, nothing stops that PR from being merged, and the broken state lands on the protected branch.

The useful takeaway: in Codeac, add a branch protection rule that marks specific status checks as required. Once the rule exists, a pull request cannot be merged until every listed check reports success.

What a required status check does

A status check is a pass/fail signal posted to a pull request by an external process — a CI job, a security scan, or a custom webhook. A branch protection rule is a repository-level policy that Codeac evaluates against pull requests targeting the protected branch.

When you mark a check as required, Codeac blocks the merge if that check fails or has not reported. The interface shows a red error banner naming the failed check and linking to its detailed log, and the merge button stays disabled. Supported check sources include any CI job name, a security scan identifier, or a custom webhook status, so the same mechanism can gate builds, dependency audits, or coverage thresholds.

Prerequisites

• Admin or maintainer rights on the repository. Contributors with lower roles cannot create or modify branch protection rules.
• Checks that already exist. The rule gates merges; it does not run anything. Your CI jobs, scans, or webhooks must already post statuses to pull requests.
• The exact status name. Rules match checks by name — for example ci/build. A renamed or misspelled job name silently breaks the gate.
• A decision about the target branch the rule will protect, typically the main integration branch.

Configure the rule

1. Open the repository and go to Settings → Branches → Branch protection rules.
2. Add a new rule for the branch you want to protect.
3. In the protection pane, mark the status check as required by entering its exact name, for example:
   

   ci/build

4. Save the rule and confirm it appears in the list of protection rules.

If you manage multiple gates, repeat the check-name entry for each one. Every listed check must report success before the merge button enables.

Complementary rules in the same pane

The same protection pane offers additional rules that tighten the policy. They are independent switches — enable only what your workflow actually supports.

Rule	What it enforces	Practical trade-off
Require linear history	No merge commits; history stays a single line via rebase or squash	Cleaner history, but contributors must rebase or squash before merging
Require signed commits	Commits must carry a valid signature	Stronger provenance, but every contributor needs signing configured locally
Include administrators	The rules also apply to admins, removing the bypass	No exceptions during incidents unless the rule is temporarily edited

Verify the gate actually blocks a merge

Configuration alone proves nothing. Run a deliberate negative test:

1. Open a pull request containing a commit that makes the required check fail — for example, a change that causes the ci/build job to exit with code 1.
2. Confirm the merge button is disabled and a red error banner appears, naming the failed check and linking to its log.
3. Check the repository audit log, or the webhook payload delivered to your listener, for a protection_rule_evaluation event recording the enforcement decision for that pull request.
4. Fix the code or re-run the job so the check passes, then confirm the merge button enables and the banner clears.

Step 3 is the useful diagnostic: it distinguishes "the rule evaluated and blocked" from "the check never ran," which look identical in the UI.

Recovery options when open PRs get blocked

Updating a protection rule re-evaluates currently open pull requests. A PR that satisfied the old rule but not the new one is blocked from merging until the failing check passes or the code is adjusted; it may display a merge-conflict-style indicator even when the diff itself is clean. Practical responses:

• Let the check catch up. Push a fix or re-run the job so the required check reports success; the block clears on the next evaluation.
• Correct a bad rule. If the block comes from a typo in the check name or a rule added by mistake, edit the rule to fix or remove the required check. This is the rollback path — the rule is the only state you changed.
• Sequence rule changes with the team. Announce stricter rules before saving them, so open PRs are not surprised by a new gate mid-review.

Limits to keep in mind

• The rule is a gate, not a runner. If CI is misconfigured and never posts a status, PRs stay blocked rather than failing loudly.
• Exact-name matching means renaming a CI job breaks the gate silently. After any job rename, reopen the rule and confirm the name still matches.
• Only admins and maintainers can change rules, so a contributor cannot self-serve a bypass.
• Menu labels, rule names, and the protection_rule_evaluation event should be confirmed against the Codeac documentation for your deployment version — UI surfaces and event payloads can change between releases. Treat the steps above as a template and verify the exact labels before rolling the rule out repository-wide.

The fastest end-to-end check: one deliberately failing pull request, one disabled merge button, one audit-log entry. If all three appear, the gate works.