Require approval from a human (i.e. user 'danny') before MRs can be merged

This GitLab instance runs the Enterprise Edition codebase but without an active Premium/Ultimate license - confirmed by testing both mechanisms for requiring approval before merge:

The legacy approvals_before_merge project setting: a write to it via the API is silently accepted but has no effect (reads back as 0 regardless).
The modern approval_rules API: returns 403 Forbidden.

Both are consistent with "Merge request approvals" being a licensed-only feature not available on this instance - effectively we only have Community Edition-level capability here. There is no supported way to enforce a required human approval on this GitLab instance as it's currently licensed.

Danny confirmed buying a Premium/Ultimate license isn't an option. The agreed path forward: #40 tracks migrating this project to Forgejo (Danny's planned infrastructure), which has license-free branch protection with required-approval support - that's the actual fix for this ticket. Linked #40 here as relates_to (GitLab's blocks link type is also license-gated on this instance, so I couldn't set a formal blocking relationship - #40 blocks this one in spirit).

In the meantime this remains a documented process/convention only: I do not merge my own MRs without your explicit review and go-ahead, same as every MR this session. Two minor hardening settings did take effect and are staying on regardless: merge_requests_author_approval: false and merge_requests_disable_committers_approval: true (both already prevented/now prevent an MR's own author or committer from approving it, for whatever that's worth without a required-approval count backing it up).

Leaving this open, blocked on #40.

**Investigation findings.** This GitLab instance runs the Enterprise Edition codebase but without an active Premium/Ultimate license - confirmed by testing both mechanisms for requiring approval before merge: - The legacy `approvals_before_merge` project setting: a write to it via the API is silently accepted but has no effect (reads back as `0` regardless). - The modern `approval_rules` API: returns `403 Forbidden`. Both are consistent with "Merge request approvals" being a licensed-only feature not available on this instance - effectively we only have Community Edition-level capability here. There is no supported way to enforce a required human approval on this GitLab instance as it's currently licensed. Danny confirmed buying a Premium/Ultimate license isn't an option. The agreed path forward: **#40** tracks migrating this project to Forgejo (Danny's planned infrastructure), which has license-free branch protection with required-approval support - that's the actual fix for this ticket. Linked #40 here as `relates_to` (GitLab's `blocks` link type is *also* license-gated on this instance, so I couldn't set a formal blocking relationship - #40 blocks this one in spirit). In the meantime this remains a documented process/convention only: I do not merge my own MRs without your explicit review and go-ahead, same as every MR this session. Two minor hardening settings did take effect and are staying on regardless: `merge_requests_author_approval: false` and `merge_requests_disable_committers_approval: true` (both already prevented/now prevent an MR's own author or committer from approving it, for whatever that's worth without a required-approval count backing it up). Leaving this open, blocked on #40.

claude commented

2026-07-07 18:02:53 +01:00

(Migrated from gitlab.keyop.co.uk)

mentioned in issue danny/cs-bifrost#8

claude commented

2026-07-07 18:24:17 +01:00

(Migrated from gitlab.keyop.co.uk)

mentioned in issue danny/cs-bifrost#6

claude commented

2026-07-09 13:33:16 +01:00

Collaborator

Now resolved by the migration to Forgejo (#40): branch protection on main has Required approvals set to 1, with the approval whitelist restricted to danny's account. Confirmed with Danny directly - a PR genuinely cannot be merged without his explicit approval; this is enforced by the platform, not just a convention.

This was specifically blocked on GitLab because the instance runs unlicensed EE, which silently no-ops approvals_before_merge (see the investigation on this issue's original discussion) - Forgejo has no such licensing gate, so the same requirement that was impossible there works here out of the box.

Now resolved by the migration to Forgejo (#40): branch protection on `main` has `Required approvals` set to `1`, with the approval whitelist restricted to `danny`'s account. Confirmed with Danny directly - a PR genuinely cannot be merged without his explicit approval; this is enforced by the platform, not just a convention. This was specifically blocked on GitLab because the instance runs unlicensed EE, which silently no-ops `approvals_before_merge` (see the investigation on this issue's original discussion) - Forgejo has no such licensing gate, so the same requirement that was impossible there works here out of the box.

claude

2026-07-09 13:33:16 +01:00

closed this issue
added
Claude-fixed
and removed
On Hold
labels

Rows
Columns

Require approval from a human (i.e. user 'danny') before MRs can be merged #39