Fjord

Move your CI to Forgejo Actions.

GitHub Actions keeps its syntax; the porting work is in the actions and runners it depends on. GitLab CI is a deliberate rewrite. Either way, secrets are re-entered and you confirm a green run before you cut over.

The shape of the work

Forgejo Actions runs the same workflow model as GitHub Actions. Pipelines coming from GitHub keep their shape; what changes is the actions they call and the runners they target. GitLab CI is a different model, so it is an explicit rewrite rather than a port. Secrets are the one constant: their values never migrate from any source, so you re-enter them on the new forge.

From GitHub Actions

  • Workflow YAML is the same shape: `on`, `jobs`, `steps`, and `runs-on` carry over. `runs-on` labels and third-party actions are where the work is.
  • Repository and organization secrets become Forgejo Actions secrets. Re-enter them; secret values never migrate.
  • Marketplace actions that only run on GitHub-hosted infrastructure or call the GitHub API need review or replacement.
  • `GITHUB_TOKEN`-scoped steps map to Forgejo’s automatic token; adjust any that assume GitHub-only API surface.

From GitLab CI

  • `.gitlab-ci.yml` has no automatic port: `stages`, `rules`, `needs`, and `extends` are rewritten as Forgejo Actions jobs and conditions.
  • CI/CD variables and protected/masked variables become Forgejo Actions secrets and variables.
  • `cache:` and `artifacts:` map to caching and artifact steps; review paths and retention.
  • Container-registry and environment logic tied to GitLab is reworked against your forge and runners.

Runners and cutover

Dedicated runners on Team and Pro

Team and Pro forges can add dedicated, unmetered runners, so CI runs on capacity that is yours rather than a shared, metered pool. That is often the reason CI is the first thing teams want moved.

Confirm a green run before cutover

Port one representative pipeline first, get it green on the new runners, then move the rest. Keep the old CI running in parallel until you trust the new one; nothing forces a hard switch.

Repoint your remotes

Once CI is green, update each clone’s origin to the new instance and push to confirm. Branches, tags, and history are already there from the import.

git remote set-url origin https://<yourname>.fjord.host/<org>/<repo>.git