Repository navigation
Epic: Establish rulesets for branching, tagging, and merging #546
Description
Objective
Have GitHub, not convention, enforce how code reaches main, release branches and tags. Every change should be reviewed against its final commits and validated before it lands, and release refs should only change through the release process.
Current state
- Two overlapping rulesets target
main:mainblocks deletion.main: require PR review and CIblocks force-push, requires a PR with 1 approval, and requires thebuild-and-testcheck.
- Approvals are not dismissed when new commits are pushed (
dismiss_stale_reviews_on_push: false), although CONTRIBUTING.md says a push after an approval needs a fresh approval. - The ruleset allows the
mergemethod, but the repo settings disable merge commits. - There is no merge queue, and no workflow triggers on
merge_group. v*tags andrelease-*branches have no protection.- Anyone with write access can create branches on the upstream repo (60+ exist today).
- Rulesets are managed only in the GitHub UI, so changes are neither reviewable nor auditable in the repo.
Minimum bar
- Approvals are cleared when new commits are pushed
- Merge queue on
main(which checks it runs is decided separately) -
v*tags can only be created, moved or deleted by release managers or the release workflow -
release-*branches are protected (no deletion or force-push; changes only through PRs with CI)
Planned sub-issues
Each one is tracked as a GitHub sub-issue of this epic:
- Manage repository rulesets as code
- Combine the
mainrulesets into a singleprotect-main - Clear approvals on fresh commits
- Set up a merge queue on
main - Protect release tags
- Protect release branches
- Establish branching and tagging rules to enforce repo best practices
- [RFC] Require contributors to work from forks
Rollout
New or changed rulesets start in evaluate mode. Once the rule insights show they wouldn't block legitimate work, they switch to active.
Activity