Migrate CI from GitLab to Forgejo Actions (#40) #80
No reviewers
Labels
No labels
Bug
BuildIssue
Claude-fixed
Enhancement
In Progress
Low priority
On Hold
Rejected
Security
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
keyop-go/nfq_forwarder!80
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "issue40_migrate_to_forgejo"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Closes #40.
Replaces
.gitlab-ci.ymlwith.forgejo/workflows/ci.yml- a close translation of the samelint/build/releasejobs to Forgejo Actions syntax, using thegolang-cirunner label already registered againstregistry.keyop.co.uk/keyop/docker/golang-ci:1.26.4.Two deliberate deviations, called out in CLAUDE.md:
lint/buildrun in parallel instead of GitLab's sequential stages (neither depends on the other's output).releasestill needs both.go.modhas no dependencies on either git host.Also retargets
.goreleaser.yamlfromgitlab_urlstogitea_urls(goreleaser's Gitea client works against Forgejo unchanged) - this needs aGITEA_TOKENActions secret with repository write access before thereleasejob can actually publish. I have not set this up myself per your preference to keep Forgejo admin actions in your hands - could you add it (Settings -> Actions -> Secrets, nameGITEA_TOKEN)?Still to verify empirically once this runs: whether
runs-on: golang-ciactually pulls the image cleanly (registry credentials on the runner host are outside this repo), and whetheractions/checkout@v4resolves at all from this runner (no actions mirror is visible from here) - I'll watch the real run and fix forward if either breaks.Separate observation, not acted on: the old GitLab pipeline had a
teststage declared with no job ever assigned to it -go test ./...was never actually run in CI, only lint/static checks. Flagging it since it seems like an oversight, not fixing it here (bigger scope than this migration).make lint/test/build/packageall pass locally.CI is fully green now (
lint/buildsucceed,releasecorrectly skips on a non-tag push) - confirmed end to end via a real run, not just config review.Root causes hit and fixed along the way (all infra-side, resolved outside this repo by Danny):
registry.keyop.co.ukneeded auth the runner did not have - resolved by moving the golang-ci image to Forgejos own registry instead (forgejo.keyop.co.uk/keyop-go/golang-ci).client_max_body_size(413) - fixed by both raising the limit and trimming the image (go install leaves module/build caches behind - cleaning them dropped a 3.97GB layer to 229MB).actions/checkout@v4needs Node.js inside the job container (Forgejo runs JS actions vianodein-container, not on the runner host) - addednodejsto the image.forgejo.keyop.co.uk(nested Docker-in-Docker breaks thehost-gatewaymagic value - it resolves to the nested dinds own bridge gateway, not the real host) - fixed with an explicit--add-host=forgejo.keyop.co.uk:<real-host-ip>in the runnerscontainer.options.actions/upload-artifact@v4uses a newer artifact protocol Forgejo does not support yet (GHESNotSupportedError) - downgraded to@v3.Still outstanding before merge: a
GITEA_TOKENActions secret needs provisioning for thereleasejob to actually publish on a real tag push - that path is config-reviewed but not yet exercised end to end (deliberately not testing with a real tag in this PR).Forgejo rejects a stored secret literally named GITEA_TOKEN (blocks the GITEA_/FORGEJO_/GITHUB_ prefixes, to stop secrets shadowing its own auto-injected ones) - but that's only a restriction on the secret's stored name, not on what environment variable name a workflow step can expose it as. The secret is now named RELEASE_TOKEN and mapped to the GITEA_TOKEN env var goreleaser's Gitea client actually reads: env: GITEA_TOKEN: ${{ secrets.RELEASE_TOKEN }}All looks good to me.