Jeppe B
6b5ac8a8b3
## Purpose After-activation canary for repository ruleset `19051697`. ## Evidence before activation - preparation PR #172 established stable `Required CI` - strict-current-base remediation PR #174 passed `Required CI` and Qodana - merged master run `29501928124` completed with 43 successful jobs and one intentional skip - effective master rules were audited after activation ## Canary acceptance - merge is blocked while `Required CI` is pending - the exact `Required CI` check comes from GitHub Actions integration `15368` - only squash merge is accepted - the branch is deleted automatically after merge
59 lines
2.8 KiB
Markdown
59 lines
2.8 KiB
Markdown
# Default branch protection
|
|
|
|
The intended repository ruleset is stored in
|
|
[`rulesets/protect-default-branch.json`](rulesets/protect-default-branch.json).
|
|
It targets the configured default branch and requires pull requests, the strict
|
|
`Required CI` check from GitHub Actions, resolved review conversations,
|
|
squash-only merges, and linear history. Branch deletion and force pushes are
|
|
blocked. Qodana remains advisory and is not part of the required gate.
|
|
|
|
The ruleset's `RepositoryRole` actor ID `5` is GitHub's built-in Administrator
|
|
role. Its `pull_request` bypass mode permits an administrator to bypass rules
|
|
only while merging an existing pull request; it does not permit a direct push.
|
|
|
|
## Repository settings
|
|
|
|
Keep squash merge enabled and disable merge commits and rebase merge. Enable
|
|
auto-merge, the update-branch option, and automatic deletion of merged head
|
|
branches. Keep the Actions token read-only and do not allow Actions to approve
|
|
pull-request reviews.
|
|
|
|
## Activation and verification
|
|
|
|
1. Confirm a pull request and a `master` push each produce exactly one
|
|
successful `Required CI` check from GitHub Actions integration `15368`.
|
|
2. For the initial ruleset POST, override the committed JSON's `enforcement`
|
|
value to `disabled`, then compare GitHub's normalized API response with this
|
|
file.
|
|
3. PUT the exact committed JSON to the inspected ruleset to activate it.
|
|
4. Open a canary pull request and confirm that pending or failing CI, unresolved
|
|
conversations, and an out-of-date branch block merging; only squash merge is
|
|
available.
|
|
5. After merging, confirm the head branch is deleted and the post-merge full
|
|
E2E, frontend release, and mobile release guards still run.
|
|
|
|
If validation exposes a blocker, disable the ruleset rather than deleting it so
|
|
its configuration and history remain available.
|
|
|
|
## Activation record
|
|
|
|
Repository ruleset `19051697` was activated on 2026-07-16 after preparation
|
|
PR #172 established `Required CI`, remediation PR #174 passed the strict
|
|
current-base gate, and merged master run `29501928124` completed with all 43
|
|
executed jobs successful. This documentation update is the after-activation
|
|
canary for the normal protected pull-request path.
|
|
|
|
## Normal publishing flow
|
|
|
|
Create a scoped feature branch, open a pull request to `master`, wait for
|
|
`Required CI`, update the branch if `master` advanced, resolve every review
|
|
conversation, and squash-merge. For waits expected to exceed 90 seconds, use
|
|
the workspace `scripts/ci-watch.sh` helper instead of repeatedly polling GitHub.
|
|
|
|
## Break glass
|
|
|
|
For an incident, an administrator must still open a pull request. Document the
|
|
incident and why the normal gate cannot complete, then use the PR-only bypass
|
|
when merging. Monitor all post-merge workflows and open a follow-up pull request
|
|
for any validation or remediation deferred during the incident.
|