Migrate nfq_forwarder (repo, CI, and workflows) from GitLab to Forgejo #40

New issue

2026-07-07T17:55:21+01:00

claude commented

2026-07-07 17:55:21 +01:00

(Migrated from gitlab.keyop.co.uk)

Blocks #39.

This GitLab instance is running the Enterprise Edition codebase but without an active Premium/Ultimate license, so it effectively only offers Community Edition-level features. Confirmed while investigating #39 ("Require approval from a human before MRs can be merged"): both the legacy approvals_before_merge project setting and the modern approval_rules API are unusable here - the former is silently ignored (a write to it has no effect), and the latter returns 403 Forbidden - consistent with "Merge request approvals" being a licensed-only feature. There is no supported way on this instance to enforce that an MR requires a real human approval before merging.

Since buying a GitLab Premium/Ultimate license isn't an option, the longer-term fix is to move this project (repo history, issues/MRs as far as practical, CI pipeline, and release workflow) to Forgejo instead, once Danny's planned Forgejo infrastructure is ready. Forgejo has built-in, license-free branch protection with required-approval support, which would let #39 actually be enforced rather than remaining a documented process/convention only.

Scope (to be refined once Forgejo is available):

Repository migration (history, tags, branches).
Recreating the .gitlab-ci.yml pipeline (lint/build/test/release stages) as Forgejo Actions (or equivalent CI).
Recreating branch protection + required-approval rules on the new host - this is the actual fix for #39.
Recreating the release process (tag-triggered package build/publish - see project memory on the release process) against Forgejo's release/package registry equivalents.
Deciding what happens to existing GitLab issue/MR history (full migration vs. a clean cutover with a link back to the GitLab archive).

Not started - waiting on the Forgejo infrastructure project itself to be ready first.

Blocks #39. This GitLab instance is running the Enterprise Edition codebase but without an active Premium/Ultimate license, so it effectively only offers Community Edition-level features. Confirmed while investigating #39 ("Require approval from a human before MRs can be merged"): both the legacy `approvals_before_merge` project setting and the modern `approval_rules` API are unusable here - the former is silently ignored (a write to it has no effect), and the latter returns `403 Forbidden` - consistent with "Merge request approvals" being a licensed-only feature. There is no supported way on this instance to enforce that an MR requires a real human approval before merging. Since buying a GitLab Premium/Ultimate license isn't an option, the longer-term fix is to move this project (repo history, issues/MRs as far as practical, CI pipeline, and release workflow) to Forgejo instead, once Danny's planned Forgejo infrastructure is ready. Forgejo has built-in, license-free branch protection with required-approval support, which would let #39 actually be enforced rather than remaining a documented process/convention only. **Scope** (to be refined once Forgejo is available): - Repository migration (history, tags, branches). - Recreating the `.gitlab-ci.yml` pipeline (lint/build/test/release stages) as Forgejo Actions (or equivalent CI). - Recreating branch protection + required-approval rules on the new host - this is the actual fix for #39. - Recreating the release process (tag-triggered package build/publish - see project memory on the release process) against Forgejo's release/package registry equivalents. - Deciding what happens to existing GitLab issue/MR history (full migration vs. a clean cutover with a link back to the GitLab archive). Not started - waiting on the Forgejo infrastructure project itself to be ready first.

claude commented

2026-07-07 17:55:41 +01:00

(Migrated from gitlab.keyop.co.uk)

marked as related to #39