Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
54 lines (33 loc) · 2.82 KB

CONTRIBUTING.md

File metadata and controls

54 lines (33 loc) · 2.82 KB
Raw

Contributing

Branches

staging is the testing layer between a change and main. Everything lands in staging first, gets tested there, and reaches main only when staging is merged into it.

Branch Holds Accepts
staging Changes being tested Pull requests from any branch, once CI passes
main Tested, released code Pull requests from staging only, once CI passes

Open every pull request against staging. A pull request into main from any other branch fails the Only staging merges into main check and cannot be merged. To fix it, edit the pull request and change its base branch to staging.

Testing in staging

Every pull request into staging runs the full CI: the Linux and Windows build matrix, the shader check, and the headless smoke test.

Every push to staging also leaves a playable Release build. Open the CI run for the latest staging commit in the Actions tab and download SleakCraft-staging-Windows or SleakCraft-staging-Linux from the bottom of the page. The builds are kept for 14 days.

Releasing staging to main

  1. Open a pull request from staging into main.
  2. Wait for CI to pass.
  3. Merge it with Create a merge commit.

main only allows merge commits. Squash and rebase copy staging's commits into new ones, so the two branches would stop sharing history, and every later release would replay old commits and hit conflicts that aren't real.

After a release, GitHub shows staging as behind main. The commits it is missing are the release merge commits, which change nothing on their own and need no action.

Branch protection

The rules are the JSON files in .github/rulesets/, which GitHub imports as they are: Settings → Rules → Rulesets → New ruleset → Import a ruleset.

Rule main staging
Changes arrive by pull request only ✓ ✓
No force pushes, no deletion ✓ ✓
CI must pass ✓ ✓
Source must be staging ✓
Merge method Merge commit Any

Setting it up? Import main.json only after .github/workflows/branch-policy.yml is on main. The ruleset requires the check that workflow reports, so until the workflow exists nothing can merge into main. Allow merge commits must stay on under Settings → General → Pull Requests.

Neither ruleset requires an approving review, because GitHub does not let authors approve their own pull requests. Raise required_approving_review_count once there is a second maintainer.

Nobody can bypass the rules, admins included. To get out of a jam, set the ruleset's enforcement to Disabled, fix the problem, then set it back to Active.

Required checks are matched by name, so renaming a job in ci.yml or branch-policy.yml means updating the rulesets to match.