flow: squash into dev, fast-forward the promotions #165

Merged

emi merged 1 commit from feat/ff-promotion-flow into dev

2026-08-02 00:15:43 +00:00

emi commented

2026-08-02 00:14:51 +00:00

Owner

Encodes the branch flow in the two places that can hold it: repo settings (already applied) and the docs.

Enforced repo-wide — Forgejo has no per-branch merge-style setting, so allowing only squash and fast-forward-only is the enforcement:

Hop	Style
`feat/*` → `dev`	squash
`dev` → `main`, `main` → `release`	fast-forward only

Squashing dev into main would freeze merge-base(dev, main) and make every later promotion re-apply work main already has. Fast-forwarding means a promotion creates no commit, so the branches keep identical history, and release ⊆ main ⊆ dev holds permanently. A one-time realignment (#164) already restored that invariant — the trees were identical, only promotion merge commits differed.

allow_rebase_update is untouched; the merge queue needs it.

Also adds release to pr-build.yml's branches — step one of the order BRANCHING.md prescribes for closing the missing required check on release. The check itself gets enabled only after a real PR shows the context appearing.

Encodes the branch flow in the two places that can hold it: repo settings (already applied) and the docs. **Enforced repo-wide** — Forgejo has no per-branch merge-style setting, so allowing only squash and fast-forward-only is the enforcement: | Hop | Style | |---|---| | `feat/*` → `dev` | squash | | `dev` → `main`, `main` → `release` | fast-forward only | Squashing `dev` into `main` would freeze `merge-base(dev, main)` and make every later promotion re-apply work `main` already has. Fast-forwarding means a promotion creates no commit, so the branches keep identical *history*, and `release ⊆ main ⊆ dev` holds permanently. A one-time realignment (#164) already restored that invariant — the trees were identical, only promotion merge commits differed. `allow_rebase_update` is untouched; the merge queue needs it. Also adds `release` to `pr-build.yml`'s branches — step one of the order BRANCHING.md prescribes for closing the missing required check on `release`. The check itself gets enabled only after a real PR shows the context appearing.

emi added 1 commit 2026-08-02 00:14:52 +00:00

flow: squash into dev, fast-forward the promotions

PR build (required check) / changes (pull_request) Successful in 8s

Details

shell-lint / shellcheck (pull_request) Successful in 7s

Details

secrets-guard / encrypted (pull_request) Successful in 10s

Details

PR build (required check) / build-backend (pull_request) Has been skipped

Details

PR build (required check) / build-frontend (pull_request) Has been skipped

Details

PR build (required check) / validate-observability (pull_request) Has been skipped

Details

PR build (required check) / gate (pull_request) Successful in 3s

Details

ea613e33ca

Forgejo cannot scope merge styles per branch — they live on the repo's
pull-request unit, and BranchProtection carries no merge-style or linear-history
field in 9.0.3. So the chain is enforced repo-wide by allowing exactly two
styles: squash and fast-forward-only. Merge commits and rebase merges are off.

Squash belongs on the short-lived hop. Squashing dev into main would put a
commit on main that does not have dev's commits as ancestors, freezing
merge-base(dev, main); every later promotion would then list all commits since
that stale point and re-apply changes main already has. Fast-forwarding the
promotions instead means a promotion creates no commit at all, so the three
branches keep identical history rather than merely identical trees, and
`release ⊆ main ⊆ dev` holds permanently.

Rebase-updates stay enabled. They are a different setting from rebase merges,
and BRANCHING.md is right that the merge queue 403s without them.

Also adds `release` to pr-build.yml's pull_request branches. This is step one of
the order BRANCHING.md prescribes for closing the missing check on release:
teach the workflow to fire there, confirm on a real PR that the context appears,
and only then require it. Requiring a context nothing produces is what makes a
production promotion unmergeable with a 405 that names no cause.