GitHub Repository Rules

develop requires exactly one status context, PR checks, and requires it in the non-strict form.

strict: true — GitHub’s "require branches to be up to date before merging" — is deliberately not used. It forces every pull request to rebase onto the latest develop and re-run the suite before it may merge. With a suite measured in double-digit minutes, two pull requests ready at the same time serialise into a rebase-and-wait queue where the second is invalidated by the first merging. The protection it buys — catching semantic conflicts between changes that merge cleanly but interact badly — is not worth that cost at this repository’s rate of change.

main receives merges from release and hotfix branches, driven by gitflow:release-finish and gitflow:hotfix-finish. Those merges must not be gated on a pull request check:

Gating main therefore adds no assurance and introduces a class of release failure that has to be repaired manually.

Neither required_approving_review_count nor require_code_owner_review is set.

This is a deliberate reversal of an earlier standard, and the reason is worth recording, because the earlier version failed silently rather than visibly. A rule requiring one approving review cannot be satisfied by a sole maintainer — GitHub does not permit approving one’s own pull request. Configured as required, it makes every pull request permanently unmergeable; configured with an administrator bypass, it is satisfied by the one person it was written to constrain. The observed outcome was neither: the rulesets carrying it were created and then left at enforcement: disabled, so the repositories ran with no protection at all while appearing, to anyone reading the configuration, to be protected.

A machine-checkable gate does not have that failure mode. The suite either ran and passed or it did not.

Automated reviewers remain valuable and remain advisory. A CoPilot or bot review that raises a real defect should be addressed on its merits, not because a rule compels it.

Every repository carries .github/CODEOWNERS. With no review requirement in force its effect is to request reviewers automatically, not to block. It is worth keeping accurate: the request is how a reviewer learns a change touching their area exists.

Branch protection requires a named status context. Requiring a test job directly — Back-end / ✅ Test — does not work, because a path filter legitimately skips that job on a documentation-only change. A required context that is skipped either blocks a good pull request or is treated as satisfied, depending on how the skip is reported.

The workflow therefore ends in a single job named PR checks that always runs, inspects the results of its dependencies itself, and exits non-zero unless every one of them either succeeded or was legitimately skipped. That job — and only that job — is the required context.

The pull_request trigger carries no paths-ignore. A required check that never runs leaves a pull request pending forever rather than mergeable, so a documentation-only or chart-only change would become unmergeable if the workflow declined to start.

Filtering happens one level down instead: a paths-filter job decides whether the expensive test job executes, that job skips when irrelevant, and PR checks still reports success. The cost of the always-on run is one short job.

This is the opposite of the convention in the push workflows, which keep their paths-ignore precisely because nothing requires their checks.

Without always(), a failed dependency causes the aggregating job to be skipped too. The required check then reports "skipped", which branch protection can treat as satisfied — a gate that opens exactly when a job fails. That is worse than no gate, because it looks like protection.

A conforming workflow runs the whole suite on every pull request that touches code. Splitting it into a fast tier that gates and a slow tier that does not would let a change which passes the fast tier and fails the slow one reach develop — the precise outcome the gate exists to prevent.

Where suite runtime is a concern, the answer is to make the suite faster, not to narrow what the gate covers. Note also that Maven already fails fast without any pipeline machinery: surefire runs before failsafe in the same invocation, so a broken unit test ends the run long before the integration suite starts.

With enforce_admins: false, a repository administrator can still push directly to a protected branch. This is what allows the release automation to complete.

The trade-off is explicit: the same setting lets an administrator merge a pull request whose checks are red. The gate is therefore fully binding on automation and on any non-administrator, and advisory for an administrator who deliberately overrides it. Setting enforce_admins: true would make the gate absolute and break every release, which is not a trade worth making.

The default GITHUB_TOKEN pushes as github-actions[bot], which is not an administrator and is therefore blocked by protection regardless of enforce_admins.

Any repository that cuts releases and has a protected develop needs a RELEASE_PAT secret — a personal access token with Contents: read+write belonging to an administrator. The shared release workflow selects it automatically and falls back to GITHUB_TOKEN:

The fallback means the omission is silent until a release is cut. Add RELEASE_PAT before enabling protection, not after — otherwise the first release after the change fails part-way through and has to be finished by hand.

Where the repository also runs the shared copilot-review.yml workflow, the same token needs Pull requests: write in addition to Contents: read+write — requesting a reviewer is a pull request write, not a contents write. A classic PAT carrying the repo scope already covers both. See GitHub Actions CI/CD for why that workflow needs a PAT rather than GITHUB_TOKEN.

A repository with nothing to run does not get a PR checks context, and develop is left unprotected rather than gated on a check that will never report. Documentation repositories are the usual case.

Both mechanisms can express this standard; the repository-level classic branch protection API shown above is the one in use, and mixing the two is what makes protection state hard to read. When auditing a repository, check both — a repository can carry a ruleset that appears to protect it while sitting at enforcement: disabled:

A ruleset at disabled enforces nothing. It is not a partial protection and it is not a warning mode.

An active ruleset can be just as quiet. The rule Automatically request Copilot code review requests the review on the pull request author’s behalf, and does nothing at all when that author holds no Copilot entitlement — no review, no error, no failed check, and nothing in the pull request timeline to show it was tried. EMS requests Copilot reviews from a workflow running under RELEASE_PAT instead, so that the entitlement spent belongs to the token owner rather than the author. See GitHub Actions CI/CD.

The required context name does not match any job the workflow produces. The context is the job’s name:, not its key. Compare against a run:

Check whether the aggregating job carries if: always(). Without it the job is skipped when a dependency fails, and the required check reports "skipped" rather than failure.

The release automation was blocked pushing to a protected branch. Confirm RELEASE_PAT exists and belongs to an administrator, then finish the branch by hand — see Development Workflow.

Not a protection problem. See Private-repo runner starvation in CI and Release Pipeline Traps: private repositories draw on a metered Actions budget, and queued jobs cancel once it is exhausted.