Migrer til fremforge fra GitLab

Denne veiledningen dekker migrering fra GitLab til fremforge. Den gjelder GitLab.com, selvhostet GitLab (CE eller EE) og GitLab Dedicated. Forskjellene mellom disse variantene viser seg mest i måten autentiseringen gjøres på, og i hvilke GitLab-spesifikke funksjoner du kan ha slått på.

Les migreringsveiledningen for GitHub først hvis du kommer fra GitHub. Noen av de selvsagte stegene er identiske, og vi gjentar dem ikke her.

Hvis du ikke har kjørt sjekklisten før migrering mot det nåværende GitLab-miljøet ditt, gjør du det først. For GitLab-migreringer markerer den spesielt include:-referanser til andre prosjekter i GitLab CI (som må løses opp manuelt) og GitLab Pages-utrullinger (som må få et nytt hjem, fordi fremforge ikke har et Pages-produkt; se steg 6).

Før du begynner

Dette trenger du på din side:

• En konto med eierrolle i GitLab-gruppen eller -gruppene du migrerer.
• Et personlig tilgangstoken i GitLab med scopene api, read_repository, read_user og read_registry.
• Administratortilgang til fremforge-organisasjonen du migrerer til.
• For migrering av CI: en oversikt over GitLab CI-maler, include:-referanser og eventuelle egne GitLab Runner-tagger som pipelinene dine er avhengige av.

Dette anbefaler vi:

• Frys merges til standardbranchene under migreringen.
• Kontroller ett repository fra start til slutt først. GitLab CI-pipelines er mer forskjellige fra Forgejo Actions i oppbygningen enn GitHub Actions er, så tilpasningsarbeidet per repository er større.
• Hvis du har mange include:-referanser til andre prosjekter i GitLab CI, kartlegger du avhengighetsgrafen før du begynner å migrere, så du ikke ender opp med halvt migrerte pipelines som refererer til maler de ikke lenger kan se.

Tidsanslag:

• Ett lite repository med enkel .gitlab-ci.yml: 30–60 minutter inkludert tilpasning av pipelinen.
• Middels stort repository med middels kompleks CI (DAG, needs:, egne runner-tagger): 2–4 timer.
• Massemigrering av 20–50 repositoryer der mange deler include:-maler i GitLab CI: 3–5 ingeniørdager, der mesteparten går med til konvertering av CI.

Matrise over funksjonsdekning

For sikkerhet og autentisering gjelder den samme matrisen som i matrisen for GitHub-migrering: fremforge leverer de samme sikkerhetsmekanismene uansett kilde. fremforge setter nye organisasjoner til Git-tilgang bare over HTTPS som standard (SSH slått av som standard siden 2026-05-22), med den forhåndsregistrerte OAuth-appen for Git Credential Manager; utviklerne får MFA via organisasjonens IdP ved hver fornyelse ved push. GitLab-spesifikke punkter:

Steg 1: Migrering av repository og historikk

Forgejos innebygde importverktøy støtter GitLab som kilde. Det kopierer hele Git-historikken, issues, merge requests (importert som pull requests), kommentarer, etiketter, milepæler, wiki-innhold og utgivelser.

Med det innebygde importverktøyet (via webgrensesnittet)

Fra administrasjonsgrensesnittet i fremforge for organisasjonen din:

1. Klikk + → Ny migrasjon.
2. Velg GitLab som kilde.
3. Lim inn URL-en til GitLab-prosjektet (f.eks. https://gitlab.com/acme/backend).
4. Lim inn det personlige tilgangstokenet ditt for GitLab.
5. Kryss av for innholdstypene som skal importeres: Wiki, Issues, Merge requests, Utgivelser, Etiketter, Milepæler.
6. Velg målorganisasjon og navn på repositoryet i fremforge.
7. Klikk Migrer repository.

Med API-et (skriptbart)

# 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 @-

Slik tilsvarer GitLab-begrepene fremforge

GitLab og Forgejo bruker ikke det samme vokabularet. Importverktøyet håndterer de vanlige tilfellene:

Undergrupper

GitLab støtter undergrupper i vilkårlig mange nivåer. fremforge (Forgejo) bruker en flat modell med organisasjon og repository. Hvis GitLab-strukturen din er company / department / team / project, bestemmer du før migreringen om du vil:

1. Slå sammen til én organisasjon: alle prosjekter blir repositoryer av typen <company-slug>/<team>-<project> under én organisasjon. Enklere tilganger, men noe av hierarkiet går tapt.
2. Én organisasjon per gruppe på øverste nivå: <company-department-slug> med flate repositorynavn. Hierarkiet på avdelingsnivå går tapt.
3. Én organisasjon per undergruppe: flere organisasjoner, flere brukere å administrere, og hver faktureres for seg. Bare aktuelt hvis undergruppene virkelig har atskilte krav til fakturering og tilgang.

Importverktøyet støtter alternativ 1 eller 2 direkte. Alternativ 3 krever at du oppretter flere fremforge-organisasjoner og kjører importen N ganger.

Steg 2: Secrets og CI/CD-variabler

GitLab lagrer CI/CD-variabler på instans-, gruppe-, prosjekt- og miljønivå. fremforge Actions støtter secrets og variabler på organisasjons-, miljø- og repositorynivå: et hierarki med tre nivåer som passer godt til de vanlige tilfellene i GitLab.

Viktig: CI/CD-variabler i GitLab som er merket «masked», eksporterer ikke verdiene sine via API-et. Du må enten kjenne verdien eller hente den fra kilden der du oppbevarer secrets. Det er samme begrensning som ved migrering av secrets fra GitHub.

Legge inn variabler på nytt

For hver CI/CD-variabel i GitLab avgjør du:

• Er det en langlivet skylegitimasjon (AWS-tilgangsnøkkel, secret for en service principal i Azure, AK/SK i T Cloud Public)? Sterk anbefaling: erstatt den med OIDC-føderasjon til målskyen (se steg 4 nedenfor) i stedet for å migrere den statiske legitimasjonen.
• Er det en beskyttet variabel (GitLab-begrep, bare tilgjengelig for beskyttede brancher/tagger)? fremforge har det tilsvarende via miljø-secrets. Sett opp målmiljøet med tilgang som styres av branchbeskyttelse, og avgrens secreten dit.
• Er det en filvariabel (GitLab lagrer filinnhold med flere linjer som en variabel)? fremforge støtter det samme via vanlig lagring av secrets. Lim inn innholdet med flere linjer; runneren gjør det tilgjengelig som den navngitte miljøvariabelen når jobben kjører.

Sett variabler og secrets i administrasjonsgrensesnittet i fremforge på tilsvarende nivå: Innstillinger → Secrets (organisasjonsnivå) eller Repository → Innstillinger → Secrets (repositorynivå).

Steg 3: Konvertering fra GitLab CI til Forgejo Actions

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

Det finnes ikke noe automatisk konverteringsverktøy. Automatisk konvertering står på veikartet, avhengig av etterspørsel fra kunder. Ved lansering leverer vi dokumentasjon og manuelle konverteringsmønstre for de vanlige tilfellene.

Konverteringsmønstre

Stages → jobber med needs:

GitLab CI organiserer pipelines i sekvensielle stages. Forgejo Actions organiserer dem i parallelle jobber med eksplisitte DAG-avhengigheter 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

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: → gjenbrukbare workflower eller sammensatte actions

extends: i GitLab CI arver jobbkonfigurasjon. Forgejo Actions har to motsvarigheter:

1. Gjenbrukbare workflower (workflow_call) for å arve hele jobber på tvers av workflower.
2. Sammensatte actions (runs: using: composite) for å arve sekvenser av steg.

Konverteringen er manuell: finn foreldrejobben for .extends: i GitLab, kopier script: og oppsettet dens til en sammensatt action under .forgejo/actions/<name>/action.yml, og kall den deretter med uses: ./.forgejo/actions/<name> fra workflowene som bruker den.

include:-maler fra andre prosjekter

include: project: i GitLab CI henter CI-konfigurasjon fra et annet prosjekt. Det finnes ingen direkte motsvarighet i Forgejo Actions. Gjenbrukbare workflower (uses: owner/repo/.forgejo/workflows/template.yaml@ref) er det nærmeste og virker innenfor samme fremforge-organisasjon.

For migreringer med delte malprosjekter (vanlig i organisasjoner med egne CI-plattformteam) migrerer du malrepositoryet først og oppdaterer uses:-referansene i repositoryene som bruker dem, som en del av deres egen migrering.

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

GitLab CI har tre overlappende mekanismer for betinget kjøring av jobber. Forgejo Actions bruker 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 sendes automatisk videre mellom stages. Forgejo Actions krever eksplisitt actions/upload-artifact i jobben som lager dem, og actions/download-artifact i jobben som bruker dem.

cache: → actions/cache

cache: i GitLab CI tilsvarer actions/cache@v4 med samme semantikk for cache-nøkkel og restore-nøkkel.

services: → kjør sidevogner i steg (IKKE services:-blokken i workflowen)

services: i GitLab CI (sidevogner som Postgres/Redis osv.) kan i dag IKKE oversettes til en services:-blokk i fremforge: Forgejo Actions har begrenset støtte for services:-blokken. Deklarasjonene tolkes uten feil, men starter aldri noe, så testen din vil koble til localhost:5432 og feile. Workflower som er avhengige av den innebygde services:-blokken, vil ikke virke.

Den støttede veien er å starte sidevognen eksplisitt i et steg (Docker er tilgjengelig på runneren, se Runner-imager, så docker run -d postgres:16 i et oppsettsteg virker), eller, mye vanligere, å kjøre avhengigheten direkte med det språkets økosystem tilbyr (Testcontainers for Java, pytest-docker for Python, testcontainers-go osv.). For testoppsett med flere containere er et kall til docker compose i VM-en inne i et steg det idiomatiske mønsteret.

Støtte for den innebygde services:-blokken står på plattformens veikart. Inntil den kommer, er rådet ved migrering: skriv om services:-blokker fra GitLab til docker run / docker compose / testcontainers i steg, ikke til services:-blokker i Forgejo.

Runner-tagger

tags: i GitLab CI velger bestemte runnere. runs-on: i Forgejo Actions oppnår det samme. De hostede runnerne fremforge leverer, bruker etiketten fremforge (se Runner-imager for runnerens operativsystem og verktøy). Egne runnere kan registreres med egne etiketter, og runs-on: retter seg mot dem etter etikettnavn.

Hvis GitLab CI-en din var avhengig av bestemte private runnere (tags: [gpu], tags: [macos], tags: [on-prem]), må disse egne runnerne settes opp i fremforge via registreringsflyten for egne runnere (BYO). fremforges hostede runnere er bare Linux amd64 (se Runner-imager); GPU og macOS er ikke tilgjengelig i standardplanen.

Steg 4: OIDC-føderasjon for utrullinger

Hvis GitLab CI-pipelinene dine ruller ut til skyinfrastruktur, er beste praksis ved migrering å erstatte langlivet legitimasjon med OIDC-føderasjon. fremforge støtter OIDC-tokenføderasjon til T Cloud Public direkte; for AWS, Azure og GCP virker de vanlige mønstrene for OIDC-føderasjon.

Oppsett:

1. I administrasjonsgrensesnittet i fremforge: Innstillinger → OIDC Federation → Add target.
2. For T Cloud Public: oppgi URN-en til mål-agencyen. Runner-workflowen mottar en kortlivet, avgrenset JWT som agencyen i T Cloud Public stoler på og bytter mot avgrenset legitimasjon.
3. For AWS/Azure/GCP: sett opp OIDC-tilliten i målskyens IAM med https://frem.sh/_app/runner/oidc som utsteder (én global utsteder for alle kunder; isolasjonen mellom kunder håndheves via en betingelse på claimen repository_owner, samme mønster som i GitHub Actions). Se build/runners/oidc/ for JWKS-endepunktet, hele settet med claims og eksempler på tillitspolicyer per sky.

Etter oppsettet bruker workflowene føderasjonen i stedet for statiske nøkler. Hver runner-jobb mottar et kortlivet OIDC ID-token på $ACTIONS_ID_TOKEN_REQUEST_URL og bytter det mot avgrenset legitimasjon for T Cloud Public når jobben 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 innpakningsaction som skjuler curl-kallene, er planlagt; formen over holder den rå OIDC-kontrakten synlig og virker i dag.

Slett de tilsvarende statiske legitimasjons-secretene både i GitLab og i fremforge.

Steg 5: Ny registrering av SSH-nøkler

Samme prosess som i GitHub-migrering, steg 4. Hver utvikler legger til sin offentlige SSH-nøkkel på fremforge-kontoen sin.

SSH-sertifikatutstedere (en funksjon i GitLab EE) importeres via <your-org>/_admin/auth-policy: seksjonen for SSH CA ligger under bryteren «Allow SSH protocol» (lagt inn i Autentiseringspolicy 2026-05-26). Samme administrasjonsgrensesnitt som ved GitHub-migrering; se seksjonen om SSH-sertifikatutsteder for detaljer om oppsettet.

Steg 6: GitLab Pages → ekstern hosting (ingen Pages-motsvarighet i Forgejo)

fremforge leverer ikke noe Pages-produkt. Upstream-Forgejo har ingen Pages-modul, og vi har ikke bygget en. Migreringer fra GitLab Pages må havne et annet sted; velg alternativet som passer for deg:

1. Markdown-dokumentasjon som lå i et Pages-nettsted basert på en repository-wiki: slå på tilvalget for fremforges offentlige dokumentasjonswiki på det migrerte repositoryet. Wikien på frem.sh/<org>/<repo>/wiki[/...] leverer ferdig visningsklar Markdown med anonym lesetilgang slått på per repository. Merk: den leverer visningsklar Markdown, ikke vilkårlig statisk HTML/JS, så den dekker Pages-nettsteder i dokumentasjonsstil, ikke Pages-utrullinger av enkeltside-apper.

2. Statiske HTML/JS-nettsteder (enkeltside-apper, utdata fra Hugo / Jekyll / Astro): host dem eksternt og sett opp CNAME fra ditt eget domene. Fornuftige valg med tanke på EU er blant annet Bunny Edge Storage + Bunny CDN (samme oppsett som fremforges egen markedsføringsside bruker), Cloudflare Pages, Netlify eller Vercel. Koble til bygget igjen via runner-workflower i fremforge som ruller ut ved push.

3. Bare eget domene: hvis du tidligere brukte GitLab Pages for TLS-sertifikatet til det egne domenet (i stedet for byggesteget), peker du DNS-en til den eksterne verten og bruker fremforges OIDC-føderasjon for runnere til å rulle ut direkte fra workflowen. Det trengs ingen proxy gjennom fremforge.

Hvis du har en ikke-triviell GitLab Pages-pipeline (egen CI, omdirigeringer, utrullinger per branch), sender du e-post til support@frem.sh. Vi kan gå gjennom hvilken ekstern hosting som passer i ditt tilfelle, før du binder deg til en migreringsplan.

Steg 7: Ny tilkobling av tredjepartsintegrasjoner

GitLabs integrasjoner (webhook-mål, Jira-synkronisering, Slack-varsler osv.) kobles til på nytt på samme måte som i GitHub-migrering, steg 5. De fleste integrasjoner har støtte for Forgejo rett ut av boksen.

GitLab-spesifikke integrasjoner uten direkte motsvarighet:

• Samling i GitLab Security Dashboard: visningen Findings i administrasjonsgrensesnittet i fremforge fyller samme rolle for den innebygde forsyningskjedestakken.
• Value Stream Analytics / DORA-målinger: fremforge leverer DORA-målinger (utrullingsfrekvens, ledetid, feilrate for endringer, MTTR); se Organisasjonsadministrasjon → DORA. Det trengs ikke noe eksternt verktøy via webhook-hendelser og avspørring av API-et.

Steg 8: Kontroller og fas ut

Som i GitHub-migrering, steg 7:

1. Klon, bygg og kontroller at testene går gjennom.
2. Kjør en eksempel-PR gjennom pre-receive-skanneren, avhengighetsskanneren og verifiseringen av signerte commits.
3. Kontroller at webhooker leveres.
4. Kontroller SSO-innlogging for hver bruker.
5. Oppdater dokumentasjonen med de nye URL-ene.
6. Etter 30 dager med vellykket drift arkiverer du GitLab-prosjektene (ikke slett dem).

Vanlige fallgruver ved GitLab-migreringer

Konvertering av pipelines tar lengre tid enn du tror.

En kompleks .gitlab-ci.yml med mange stages, DAG-er, extends:, include: og services: kan ta en halv dag per repository å flytte riktig. Beregn 2–4 timer per pipeline av middels kompleksitet. Kompatibilitetsmatrisen på docs.frem.sh/marketplace-compat handler om GitHub Actions; for mønstre som er spesifikke for GitLab CI, bruker du steg 3 i denne veiledningen og dokumentasjonen for Forgejo Actions.

Godkjenningsregler for merge requests

GitLabs godkjenningsregler (krev N godkjennere, bestemte godkjennergrupper, godkjenning basert på kodeeiere) tilsvarer Forgejos regler for branchbeskyttelse, men med mindre finkornethet. Hvis GitLab-prosjektet ditt er avhengig av avanserte godkjenningsregler (f.eks. «andre godkjennere for sikkerhetsfølsomme stier»), bør du vurdere om Forgejos modell med påkrevde reviewere basert på CODEOWNERS er tilstrekkelig, før migreringen.

Funksjoner i GitLab Premium/Ultimate

fremforge leverer en direkte motsvarighet til GitLabs License Compliance: lisensskanning kjører Trivys lisensgjenkjenning på hver PR, klassifiserer hver avhengighet etter SPDX-policykategori og kan blokkere merge ved forbudte eller begrensede lisenser; resultatene vises under Sikkerhet › Funn › Lisenser. For resten av sikkerhetspakken i GitLab Ultimate (DAST, fuzz-testing, SAST med Ultimate-alvorlighetsregler, Dependency Firewall, sikkerhetsdashbord på gruppenivå) leverer fremforge ikke direkte motsvarigheter, men SAST (OpenGrep), skanning av avhengigheter/CVE-er (osv-scanner) og skanning av containere (Trivy) dekker de vanligste tilfellene. Se innlegget om AI-holdning på www.frem.sh og produktsiden for fremforge for hva vi dekker, og hva vi uttrykkelig ikke dekker.

GitLab-runnere tagget for samsvarskontekster

Runner-tagger i GitLab som compliance, restricted-network og no-internet brukes ofte for runnere som ikke kan nå det offentlige internettet. fremforges hostede runnere oppfyller dette kravet allerede i utformingen: uses:-direktiver løses opp gjennom action-speilene som bare ligger i EU, på https://frem.sh/<owner>/<repo> (den kanoniske referansen står på siden om GitHub-migrering, §Steg 3: Tilpasning av Actions-workflower), og utgående trafikk via proxy er begrenset til det speilet, speilede pakkeregistre og kundens egne utgående webhooker. Hvis samsvarskravene dine krever runnere helt uten internett, bruker du egne runnere (BYO) i ditt eget nettverk og peker dem til fremforges endepunkt for registrering av runnere.

Få hjelp

support@frem.sh med emnelinjen MIGRATION, GITLAB, <your-specific-issue>. Kunder som er tidlig ute, har direkte tilgang til teamet som bygger fremforge.

Se også: Migreringsveiledning for GitHub · Migreringsveiledning for Azure DevOps · Kompatibilitetsmatrise for de 20 mest brukte Marketplace-actions · Sjekkliste før migrering.