Migrer til fremforge fra GitLab

Denne vejledning dækker migrering fra GitLab til fremforge. Den gælder for GitLab.com, GitLab self-managed (CE eller EE) og GitLab Dedicated. Forskellene mellem de tre viser sig mest i måden, du godkender på, og i hvilke GitLab-specifikke funktioner du har slået til.

Kommer du fra GitHub, så læs vejledningen til migrering fra GitHub først. Nogle af de selvfølgelige trin er de samme, og dem gentager vi ikke her.

Hvis du ikke har kørt tjeklisten før migrering mod din nuværende GitLab-tenant, så gør det først. Specifikt for GitLab-migreringer markerer den krydsreferencer mellem projekter med GitLab CI include: (som skal viklas ud i hånden) og udrulninger med GitLab Pages (som skal have et nyt hjem, fordi fremforge ikke har et Pages-produkt; se trin 6).

Før du starter

Det skal du have på din side:

• En konto med ejerrollen i de GitLab-grupper, du migrerer.
• Et personligt adgangstoken i GitLab med scopes api, read_repository, read_user og read_registry.
• Administratoradgang til den fremforge-organisation, du migrerer til.
• Til migrering af CI: en oversigt over GitLab CI-skabeloner, include:-referencer og eventuelle egne GitLab Runner-tags, som dine pipelines afhænger af.

Det anbefaler vi:

• Stop merges til standardbranches under migreringen.
• Verificer først ét repository hele vejen igennem. GitLab CI-pipelines adskiller sig strukturelt mere fra Forgejo Actions, end GitHub Actions gør, så tilpasningen kræver mere arbejde pr. repository.
• Hvis du har mange include:-referencer på tværs af projekter i GitLab CI, så kortlæg afhængighederne, før du begynder at migrere. Ellers ender du med halvt migrerede pipelines, der henviser til skabeloner, de ikke længere kan se.

Tidsestimat:

• Ét lille repository med en enkel .gitlab-ci.yml: 30-60 minutter inklusive tilpasning af pipelinen.
• Et mellemstort repository med moderat kompleks CI (DAG, needs:, egne runner-tags): 2-4 timer.
• Massemigrering af 20-50 repositories, hvor mange deler GitLab CI include:-skabeloner: 3-5 udviklerdage, hvor konverteringen af CI fylder mest.

Sammenligning af funktioner

For sikkerhed og godkendelse gælder den samme matrix som i sammenligningen i GitHub-vejledningen: fremforge leverer de samme sikkerhedsfunktioner, uanset hvilken platform du kommer fra. Nye organisationer i fremforge har som standard Git-adgang kun over HTTPS (SSH er slået fra som standard siden 2026-05-22) med den forhåndsregistrerede OAuth-app til Git Credential Manager; udviklere får MFA gennem organisationens IdP, hver gang et push fornyer login. GitLab-specifikke punkter:

Trin 1: Migrering af repositories og historik

Forgejos indbyggede importør understøtter GitLab som kilde. Den kopierer hele Git-historikken, issues, merge requests (importeret som pull requests), kommentarer, labels, milepæle, wiki-indhold og releases.

Med den indbyggede importør (via brugerfladen)

Fra fremforges administration for din organisation:

1. Klik på + → Ny migration.
2. Vælg GitLab som kilde.
3. Indsæt GitLab-projektets URL (f.eks. https://gitlab.com/acme/backend).
4. Indsæt dit personlige adgangstoken fra GitLab.
5. Sæt flueben ved det indhold, der skal importeres: Wiki, Issues, Merge requests, Releases, Labels, Milestones.
6. Vælg målorganisationen og navnet på repositoryet i fremforge.
7. Klik på Migrate repository.

Med API’et (til scripts)

# Build the JSON body via jq so the token is JSON-string-escaped safely
# (a token containing `"` or `\` would otherwise break the body).
jq -nc \
  --arg clone_addr "https://gitlab.com/acme/backend.git" \
  --arg auth_token "$GITLAB_TOKEN" \
  --arg repo_owner "acme" \
  --arg repo_name  "backend" \
  '{clone_addr: $clone_addr, auth_token: $auth_token,
    service: "gitlab", repo_owner: $repo_owner, repo_name: $repo_name,
    wiki: true, issues: true, pull_requests: true,
    releases: true, labels: true, milestones: true,
    lfs: true}' \
| curl -X POST "https://frem.sh/api/v1/repos/migrate" \
    -H "Authorization: Bearer ${FREMFORGE_TOKEN}" \
    -H "Content-Type: application/json" \
    -d @-

Sådan svarer GitLabs begreber til fremforges

GitLab og Forgejo bruger ikke de samme ord. Importøren klarer de almindelige tilfælde:

Undergrupper

GitLab understøtter undergrupper i vilkårlig dybde. fremforge (Forgejo) bruger en flad model med organisation og repository. Hvis din GitLab-struktur er company / department / team / project, så beslut før migreringen, om du vil:

1. Samle alt i én organisation: alle projekter bliver til <company-slug>/<team>-<project>-repositories under én organisation. Enklere rettigheder, men noget af hierarkiet går tabt.
2. Have én organisation pr. gruppe på øverste niveau: <company-department-slug> med flad navngivning af repos. Hierarkiet på afdelingsniveau går tabt.
3. Have én organisation pr. undergruppe: flere organisationer, mere administration af brugere, og hver faktureres for sig. Giver kun mening, hvis undergrupperne reelt har separate krav til fakturering og adgang.

Importøren understøtter mulighed 1 og 2 direkte. Mulighed 3 kræver, at du opretter flere fremforge-organisationer og kører importen N gange.

Trin 2: Secrets og CI/CD-variabler

GitLab gemmer CI/CD-variabler på instans-, gruppe-, projekt- og miljøniveau. fremforge Actions understøtter secrets og variabler på organisations-, miljø- og repositoryniveau: et hierarki i tre niveauer, der passer fint til GitLabs almindelige tilfælde.

Vigtigt: GitLab CI/CD-variabler, der er markeret som “masked”, eksporterer ikke deres værdier via API’et. Du skal enten kende værdien eller hente den fra det system, hvor dine secrets officielt ligger. Det er samme begrænsning som ved migrering af secrets fra GitHub.

Indtast variablerne igen

For hver CI/CD-variabel i GitLab skal du afgøre:

• Er det en langtidsholdbar legitimation til en cloud (AWS-adgangsnøgle, secret til en Azure service principal, T Cloud Public AK/SK)? Vi anbefaler kraftigt at erstatte den med OIDC-føderation til målcloud’en (se trin 4 nedenfor) i stedet for at migrere den statiske legitimation.
• Er det en beskyttet variabel (et GitLab-begreb, kun tilgængelig for beskyttede branches/tags)? fremforge har det samme i form af secrets på miljøer. Sæt målmiljøet op med adgang, der er låst til beskyttede branches, og læg secreten der.
• Er det en filvariabel (GitLab gemmer filindhold over flere linjer som en variabel)? fremforge understøtter det samme med almindelig lagring af secrets. Indsæt indholdet over flere linjer; runneren stiller det til rådighed som den navngivne miljøvariabel, når jobbet kører.

Sæt variabler og secrets i fremforges administration på det tilsvarende niveau: Indstillinger → Secrets (organisationsniveau) eller Repository → Indstillinger → Hemmeligheder (repo-niveau).

Trin 3: Konvertering fra GitLab CI til Forgejo Actions

Dette er det største trin i en GitLab-migrering. GitLab CI-pipelines er bygget anderledes end Forgejo Actions: stages, jobs, extends, include, rules, artifacts og cache svarer ikke én til én til GitHub Actions’ jobs, steps, needs og uses.

Der findes ingen automatisk konverter. Automatisk konvertering står på køreplanen, hvis kunderne efterspørger den. Ved lanceringen leverer vi dokumentation og mønstre til manuel konvertering, der dækker de almindelige tilfælde.

Mønstre til konvertering

Stages → jobs med needs:

GitLab CI deler pipelines op i stages, der kører efter hinanden. Forgejo Actions deler dem op i parallelle jobs med eksplicitte DAG-afhængigheder via needs:.

GitLab CI:

stages: [build, test, deploy]

build:
  stage: build
  script: make build

test:
  stage: test
  script: make test

deploy:
  stage: deploy
  script: make deploy

Det tilsvarende i Forgejo Actions (.forgejo/workflows/main.yaml):

name: CI

on: [push, pull_request]

jobs:
  build:
    runs-on: fremforge
    steps:
      - uses: actions/checkout@v4
      - run: make build

  test:
    needs: build
    runs-on: fremforge
    steps:
      - uses: actions/checkout@v4
      - run: make test

  deploy:
    needs: test
    runs-on: fremforge
    steps:
      - uses: actions/checkout@v4
      - run: make deploy

extends: → genbrugelige workflows eller composite actions

extends: i GitLab CI arver jobkonfiguration. Forgejo Actions har to modsvarigheder:

1. Genbrugelige workflows (workflow_call) til at arve hele jobs på tværs af workflows.
2. Composite actions (runs: using: composite) til at arve sekvenser af steps.

Konverteringen sker i hånden: find forældrejobbet i .extends: i GitLab, kopiér dets script: og opsætning til en composite action under .forgejo/actions/<name>/action.yml, og kald den derefter med uses: ./.forgejo/actions/<name> fra de workflows, der bruger den.

Skabeloner på tværs af projekter med include:

include: project: i GitLab CI henter CI-konfiguration fra et andet projekt. Der findes ingen direkte modsvarighed i Forgejo Actions. Genbrugelige workflows (uses: owner/repo/.forgejo/workflows/template.yaml@ref) er det nærmeste og virker inden for samme fremforge-organisation.

Ved migreringer med fælles skabelonprojekter (almindeligt i organisationer med et CI-platformsteam) skal du migrere skabelonrepositoryet først og opdatere uses:-referencerne i de repositories, der bruger det, som en del af deres egen migrering.

rules: og only:/except: → if:-udtryk

GitLab CI har tre overlappende mekanismer til betinget kørsel af jobs. Forgejo Actions bruger samme if:-syntaks som GitHub Actions.

GitLab:

deploy:
  rules:
    - if: '$CI_COMMIT_BRANCH == "main"'
      when: on_success
    - when: never
  script: make deploy

Forgejo Actions:

deploy:
  if: github.ref == 'refs/heads/main'
  runs-on: fremforge
  steps:
    - uses: actions/checkout@v4
    - run: make deploy

artifacts: → upload-artifact / download-artifact

Artefakter i GitLab CI føres automatisk videre mellem stages. Forgejo Actions kræver et eksplicit actions/upload-artifact i det job, der laver artefaktet, og actions/download-artifact i det job, der bruger det.

cache: → actions/cache

cache: i GitLab CI svarer til actions/cache@v4 med samme semantik for cache key og restore key.

services: → kør sidevogne i steps (IKKE workflowets services:-blok)

services: i GitLab CI (sidevogne som Postgres/Redis osv.) kan i dag IKKE oversættes til en services:-blok på fremforge: Forgejo Actions har begrænset understøttelse af services:-blokken. Erklæringerne parses uden fejl, men starter aldrig noget, så din test forbinder til localhost:5432 og fejler. Workflows, der afhænger af den indbyggede services:-blok, virker ikke.

Den understøttede vej er at starte sidevognen eksplicit i et step. Docker findes på runneren (se Runner-images), så docker run -d postgres:16 i et opsætningsstep virker. Langt oftere kører man afhængigheden direkte med det, sprogets økosystem tilbyder (Testcontainers til Java, pytest-docker til Python, testcontainers-go osv.). Til testopsætninger med flere containere er et docker compose-kald i VM’en inde i et step det gængse mønster.

Understøttelse af den indbyggede services:-blok står på platformens køreplan. Indtil den kommer, lyder anbefalingen til migreringen: skriv GitLabs services:-blokke om til docker run / docker compose / testcontainers i steps, ikke til services:-blokke i Forgejo.

Runner-tags

tags: i GitLab CI vælger bestemte runnere. runs-on: i Forgejo Actions gør det samme. De hostede runnere, som fremforge stiller til rådighed, har labelen fremforge (se Runner-images for runnerens OS og værktøjer). Egne runnere kan registrere sig med egne labels, og runs-on: rammer dem på labelnavnet.

Hvis din GitLab CI afhang af bestemte private runnere (tags: [gpu], tags: [macos], tags: [on-prem]), skal de egne runnere sættes op på fremforge via registreringen af egne runnere. fremforges hostede runnere er kun Linux amd64 (se Runner-images); GPU og macOS findes ikke på standardplanen.

Trin 4: OIDC-føderation til udrulninger

Hvis dine GitLab CI-pipelines udruller til cloud-infrastruktur, er best practice at erstatte langtidsholdbare legitimationsoplysninger med OIDC-føderation under migreringen. fremforge understøtter OIDC-tokenføderation til T Cloud Public direkte; til AWS, Azure og GCP virker de almindelige mønstre for OIDC-føderation.

Opsætning:

1. I fremforges administration: Indstillinger → OIDC Federation → Add target.
2. For T Cloud Public: angiv målagenturets URN. Runner-workflowet modtager et kortlivet JWT med scope, som T Cloud Public-agenturet stoler på og bytter til legitimationsoplysninger med scope.
3. For AWS/Azure/GCP: sæt OIDC-tilliden op i målcloud’ens IAM med https://frem.sh/_app/runner/oidc som udsteder (én global udsteder for alle tenants; isolationen pr. tenant håndhæves med en betingelse på claimet repository_owner, samme mønster som i GitHub Actions). Se build/runners/oidc/ for JWKS-endpointet, det fulde sæt claims og eksempler på tillidspolitikker for hver cloud.

Efter opsætningen bruger workflows føderationen i stedet for statiske nøgler. Hvert runner-job modtager et kortlivet OIDC ID-token på $ACTIONS_ID_TOKEN_REQUEST_URL; byt det til T Cloud Public-legitimationsoplysninger med scope, når jobbet starter:

- name: Federate to T Cloud Public
  run: |
    OIDC_TOKEN="$(curl -sSf -H "Authorization: Bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \
      "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=tcloud-${ORG_SLUG}")"
    CREDS_JSON="$(curl -sSf -X POST \
      "https://iam.eu-de.otc.t-systems.com/v3.0/OS-FEDERATION/token-exchange" \
      -H 'Content-Type: application/json' \
      -d "{\"identity\":{\"id_token\":{\"id\":\"$OIDC_TOKEN\"}},\"scope\":{\"agency\":{\"name\":\"fremforge-deploy\",\"domain\":{\"name\":\"$TCLOUD_DOMAIN\"}}}}")"
    {
      echo "TCLOUD_AK=$(jq -r '.credential.access' <<<"$CREDS_JSON")"
      echo "TCLOUD_SK=$(jq -r '.credential.secret' <<<"$CREDS_JSON")"
      echo "TCLOUD_TOKEN=$(jq -r '.credential.securitytoken' <<<"$CREDS_JSON")"
    } >> "$GITHUB_ENV"

En wrapper-action, der skjuler curl-kaldene, er planlagt; formen ovenfor holder den rå OIDC-kontrakt synlig og virker i dag.

Slet de tilsvarende secrets med statiske legitimationsoplysninger i både GitLab og fremforge.

Trin 5: Ny registrering af SSH-nøgler

Samme fremgangsmåde som trin 4 i GitHub-migreringen. Hver udvikler tilføjer sin offentlige SSH-nøgle til sin fremforge-konto.

SSH-certifikatmyndigheder (en GitLab EE-funktion) importeres via <your-org>/_admin/auth-policy: afsnittet om SSH CA ligger under kontakten “Tillad SSH-protokol” (lagt ind under Godkendelsespolitik 2026-05-26). Det er samme administration som ved migrering fra GitHub; se afsnittet om SSH-certifikatmyndighed for opsætningen.

Trin 6: GitLab Pages → ekstern hosting (ingen Pages-modsvarighed i Forgejo)

fremforge har intet Pages-produkt. Forgejo upstream har intet Pages-modul, og vi har ikke bygget et. Migreringer fra GitLab Pages skal lande et andet sted; vælg den mulighed, der passer til dit behov:

1. Markdown-dokumentation, der lå på en Pages-side baseret på en repo-wiki: slå fremforges wiki til offentlig dokumentation til på det migrerede repo. Wikien på frem.sh/<org>/<repo>/wiki[/...] viser renderet Markdown med anonym læseadgang slået til pr. repo. Bemærk: den viser renderet Markdown, ikke vilkårlig statisk HTML/JS, så den dækker Pages-sider i dokumentationsstil, ikke Pages-udrulninger af single-page-apps.

2. Statiske HTML/JS-sider (single-page-apps, output fra Hugo / Jekyll / Astro): host dem eksternt, og lav et CNAME fra dit eget domæne. Fornuftige EU-venlige valg er blandt andet Bunny Edge Storage + Bunny CDN (samme stak, som fremforges egen marketingside bruger), Cloudflare Pages, Netlify eller Vercel. Forbind buildet igen med fremforges runner-workflows, der udruller ved push.

3. Kun eget domæne: hvis du tidligere brugte GitLab Pages for TLS-certifikatet til dit eget domæne (snarere end for build-trinnet), så peg din DNS på din eksterne host, og genbrug fremforges OIDC-føderation for runnere til at udrulle direkte fra workflowet. Der er ikke brug for en proxy gennem fremforge.

Hvis du har en ikke-triviel GitLab Pages-pipeline (egen CI, omdirigeringer, udrulninger pr. branch), så skriv til support@frem.sh. Så kan vi tale den rette eksterne hosting igennem for dit tilfælde, før du lægger dig fast på en migreringsplan.

Trin 7: Genforbindelse af tredjepartsintegrationer

GitLabs integrationer (webhook-mål, Jira-synkronisering, Slack-notifikationer osv.) forbindes igen på samme måde som i trin 5 i GitHub-migreringen. De fleste integrationer understøtter Forgejo direkte.

GitLab-specifikke integrationer uden direkte modsvarighed:

• Samlet visning i GitLab Security Dashboard: visningen Fund i fremforges administration tjener samme formål for den indbyggede supply chain-stak.
• Value Stream Analytics / DORA-målinger: fremforge leverer DORA-målinger (udrulningsfrekvens, gennemløbstid, fejlrate for ændringer, MTTR); se Administration → DORA. Der kræves intet eksternt værktøj med webhook-events og API-polling.

Trin 8: Verificer og udfas

Som trin 7 i GitHub-migreringen:

1. Clone, byg, og kontrollér, at testene går igennem.
2. Kør en prøve-PR gennem pre-receive-scanneren, afhængighedsscanneren og verifikationen af signerede commits.
3. Kontrollér, at webhooks bliver leveret.
4. Kontrollér SSO-login for alle brugere.
5. Opdater dokumentationen til de nye URL’er.
6. Efter 30 dages vellykket drift: arkivér GitLab-projekterne (slet dem ikke).

Almindelige faldgruber ved GitLab-migreringer

Konverteringen af pipelines tager længere tid, end du regner med.

En kompleks .gitlab-ci.yml med mange stages, DAG’er, extends:, include: og services: kan tage en halv dag pr. repository at portere korrekt. Sæt 2-4 timer af pr. pipeline af mellem kompleksitet. Kompatibilitetsmatrixen på docs.frem.sh/marketplace-compat er rettet mod GitHub Actions; til GitLab CI-specifikke mønstre bruger du trin 3 i denne vejledning og Forgejo Actions-dokumentationen.

Godkendelsesregler for merge requests

GitLabs godkendelsesregler (kræv N godkendere, bestemte grupper af godkendere, godkendelse baseret på code owners) svarer til Forgejos regler for branchbeskyttelse, men er mindre finmaskede. Hvis dit GitLab-projekt afhænger af avancerede godkendelsesregler (f.eks. “andre godkendere for sikkerhedsfølsomme stier”), så vurder før migreringen, om Forgejos model med krævede reviewere baseret på CODEOWNERS er tilstrækkelig.

Funktioner i GitLab Premium/Ultimate

fremforge har en direkte modsvarighed til GitLabs License Compliance: licensscanning kører Trivys licensdetektion på hver PR, placerer hver afhængighed i en SPDX-politikkategori og kan blokere merge ved forbudte eller begrænsede licenser. Resultatet vises under Sikkerhed › Fund › Licenser. For resten af GitLab Ultimates sikkerhedspakke (DAST, fuzz-test, SAST med Ultimates alvorlighedsregler, Dependency Firewall, Security Dashboards på gruppeniveau) har fremforge ingen direkte modsvarigheder, men SAST (OpenGrep), scanning af afhængigheder og CVE’er (osv-scanner) og scanning af containere (Trivy) dækker de mest almindelige tilfælde. Se indlægget om vores holdning til AI på www.frem.sh og fremforges produktside for, hvad vi dækker, og hvad vi udtrykkeligt ikke dækker.

GitLab-runnere med tags til compliance-sammenhænge

GitLab Runner-tags som compliance, restricted-network og no-internet bruges ofte til runnere, der ikke kan nå det offentlige internet. fremforges hostede runnere opfylder dette krav fra starten: uses:-direktiver slås op gennem de EU-baserede action-spejle på https://frem.sh/<owner>/<repo> (den autoritative beskrivelse står i GitHub-migreringen §Trin 3: Tilpasning af Actions-workflows), og udgående trafik gennem proxyen er begrænset til det spejl, spejlede pakke-registries og kundetenantens udgående webhooks. Hvis din compliance-sammenhæng kræver runnere helt uden internet, så brug dine egne runnere på dit eget netværk, og peg dem på fremforges endpoint til registrering af runnere.

Få hjælp

support@frem.sh med emnelinjen MIGRATION, GITLAB, <your-specific-issue>. Kunder, der er tidligt med, har direkte adgang til udviklingsteamet.

Se også: Vejledning til migrering fra GitHub · Vejledning til migrering fra Azure DevOps · Kompatibilitetsmatrix for de 20 mest brugte Marketplace-actions · Tjekliste før migrering.