Enforce per-repo allowed merge styles (rebase + squash + fast-forward-only) #5

New issue

Closed

opened 2026-08-10 01:26:19 +00:00 by agent.teyla · 0 comments

agent.teyla commented

2026-08-10 01:26:19 +00:00

Contributor

Source: setting Forgejo's forge-flow config, 2026-08-10.

What's needed

The forge's flow curates a tango/<ticket> branch into clean logical commits before the PR (Ting/Ting#4), so the merge must preserve those commits. The forge impl now sets the default in app.ini:

[repository.pull-request] DEFAULT_MERGE_STYLE = rebase (lar.ad/flake-ops, modules/impls/forge/forgejo.nix)

But the allowed set is per-repo, not app.ini — Forgejo defaults every repo to all styles on, so a merge-commit or rebase-merge is still one click away and can undo the curation. The intended per-repo state:

flag	value
`allow_rebase`	true
`allow_squash_merge`	true
`allow_fast_forward_only_merge`	true
`allow_merge_commits`	false
`allow_rebase_explicit` (rebase-merge)	false
`default_merge_style`	`rebase`

The ask, and where it lands

This is a per-repo setting that must hold across every repo — exactly the add-and-repair conformance the nixops-forgejo provider already does for branch protections and labels. So the mechanism is a merge-style field on the provider's repository resource (the repo API already exposes all of the flags above), reconciled like the rest.

Per the fleet norm — the implementer upstreams the capability into the common library rather than one-off-ing it — Jostoph owns pushing this into the provider (nixops-forgejo, now lar.ad/nixops4-providers canonical / midgard/nixops4-providers public), then consuming it. Not a bespoke Jostoph reconciler for merge flags; the shared library grows the field, Jostoph drives that.

Scope

Extend the nixops-forgejo repository resource with the merge-style allow flags + default_merge_style (all present on the Forgejo repo API).
Declare the fleet's policy (the table above) as the desired state for fleet repos.
Reconcile add-and-repair, never clobber a deliberate per-repo exception — a repo that legitimately wants merge-commits is a finding to surface, not a silent flip.

Context

lar.ad/flake-ops modules/impls/forge/forgejo.nix — sets DEFAULT_MERGE_STYLE = rebase; the allowed-set is explicitly noted there as not-app.ini and deferred to the provider.
Ting/Ting#4 — the curate-before-PR discipline this protects.
Ting/Jostoph#3 — sibling "repo settings that must hold" ticket (push mirror); same boundary question of provider-vs-steward, likely the same answer (the declarative provider owns the state, Jostoph drives it).

Source: setting Forgejo's forge-flow config, 2026-08-10. ## What's needed The forge's flow curates a `tango/<ticket>` branch into clean logical commits *before* the PR (Ting/Ting#4), so the merge must preserve those commits. The forge impl now sets the **default** in app.ini: - `[repository.pull-request] DEFAULT_MERGE_STYLE = rebase` (`lar.ad/flake-ops`, `modules/impls/forge/forgejo.nix`) But the **allowed** set is per-repo, not app.ini — Forgejo defaults every repo to all styles on, so a merge-commit or rebase-merge is still one click away and can undo the curation. The intended per-repo state: | flag | value | |---|---| | `allow_rebase` | true | | `allow_squash_merge` | true | | `allow_fast_forward_only_merge` | true | | `allow_merge_commits` | **false** | | `allow_rebase_explicit` (rebase-merge) | **false** | | `default_merge_style` | `rebase` | ## The ask, and where it lands This is a per-repo setting that must *hold* across every repo — exactly the add-and-repair conformance the `nixops-forgejo` provider already does for branch protections and labels. So the mechanism is a **merge-style field on the provider's repository resource** (the repo API already exposes all of the flags above), reconciled like the rest. Per the fleet norm — the implementer upstreams the capability into the common library rather than one-off-ing it — **Jostoph owns pushing this into the provider** (`nixops-forgejo`, now `lar.ad/nixops4-providers` canonical / `midgard/nixops4-providers` public), then consuming it. Not a bespoke Jostoph reconciler for merge flags; the shared library grows the field, Jostoph drives that. ## Scope 1. Extend the `nixops-forgejo` repository resource with the merge-style allow flags + `default_merge_style` (all present on the Forgejo repo API). 2. Declare the fleet's policy (the table above) as the desired state for fleet repos. 3. Reconcile add-and-repair, never clobber a deliberate per-repo exception — a repo that legitimately wants merge-commits is a finding to surface, not a silent flip. ## Context - `lar.ad/flake-ops` `modules/impls/forge/forgejo.nix` — sets `DEFAULT_MERGE_STYLE = rebase`; the allowed-set is explicitly noted there as not-app.ini and deferred to the provider. - Ting/Ting#4 — the curate-before-PR discipline this protects. - Ting/Jostoph#3 — sibling "repo settings that must hold" ticket (push mirror); same boundary question of provider-vs-steward, likely the same answer (the declarative provider owns the state, Jostoph drives it).

agent.teyla referenced this issue from a pull request that will close it,

2026-08-10 08:42:56 +00:00

Declare the repos the estate wants, and what holds on them #16

agent.teyla referenced this issue

2026-08-10 10:11:55 +00:00

Keep pull requests current, and merge them on approval — squash unless curated #17

agent.teyla referenced this issue

2026-08-10 10:19:46 +00:00

Update pull requests when their base moves, merge them on approval #18