Migrer til fremforge fra GitHub

Denne veiledningen tar et typisk GitHub-team gjennom en migrering til fremforge. Den dekker GitHub.com, GitHub Enterprise Cloud (GHEC) og GitHub Enterprise Server (GHES). Les den fra start til slutt før du begynner. Overraskelser midt i en migrering er dyre.

Ikke klar til å flytte alt på én gang? Bruke fremforge ved siden av GitHub viser hvordan du speiler repositoryer så fremforge skanner dem, og hvordan du laster opp SBOM-er fra GitHub Actions, mens flyttingen pågår.

Hvis du ennå ikke har kjørt sjekklisten før migrering mot det nåværende GitHub-miljøet ditt, gjør du det først. Den avdekker store repositoryer, bruk av LFS, avhengigheter til Marketplace-actions og tredjepartsintegrasjoner som trenger særskilt oppmerksomhet.

Før du begynner

Dette trenger du på din side:

• En konto med eierrolle i GitHub-organisasjonen du migrerer fra.
• Et personlig tilgangstoken i GitHub med scopene repo, admin:org, workflow og admin:public_key (klassisk PAT) eller tilsvarende finkornet token.
• Administratortilgang til fremforge-organisasjonen du migrerer til (organisasjonen opprettes ved registrering).
• For migrering av Actions: en oversikt over GitHub Marketplace-actions du bruker i dag, og versjonene av dem.

Dette anbefaler vi:

• Frys nye PR-er og merges til hovedbranchene du migrerer, i migreringsvinduet. Samtidige skrivinger under migreringen gir avstemmingsproblemer du ikke trenger.
• Kjør migreringen mot en testorganisasjon i fremforge som ikke er i produksjon først, hvis du er i tvil om hvordan workflowene dine lar seg tilpasse. Den gratis prøveperioden på 30 dager er laget nettopp for dette.
• Migrer ett repository fra start til slutt og kontroller at det bygger uten feil, før du massemigrerer resten.

Tidsanslag (planleggingsintervaller, ikke løfter):

• Ett lite repository (≤100 MB, ingen LFS, enkle Actions): 15–30 minutter med praktisk arbeid pluss kontroll av CI.
• Et middels stort repository (≤1 GB, noe LFS, middels komplekse Actions): 1–2 timer inkludert tilpasning av workflower.
• En massemigrering av 20–50 repositoryer: 1–2 ingeniørdager fordelt over en uke, der mesteparten går med til tilpasning av Actions og ikke selve migreringen av repositoryene.

Disse intervallene bygger på en gjennomgang av dokumentasjonen mot ytelsesegenskapene til upstream-Forgejo og 2 interne migreringer i fremverk før lansering; de faktiske tidene vil bli justert ut fra de første 5 kundemigreringene våre. De er planleggingshjelp, ikke kontraktsfestede SLA-er. Hvor lang tid en migrering tar i praksis, avhenger av: (a) antall repositoryer og samlet LFS-volum; (b) hvor komplekse Actions er, og hvor mange uses:-referanser som må skrives om mot fremforges runner-speil; (c) hvor stort team som kan ta kontrollarbeidet. Hvis du migrerer > 50 repositoryer eller har ikke-triviell bruk av Actions, bør du planlegge med minst 2× den øvre grensen som buffer og kjøre et pilotprosjekt med ett repository først.

Matrise over funksjonsdekning

Hva fremforge leverer i dag sammenlignet med GitHub Enterprise Cloud, med vekt på sikkerhet og autentisering, som kundene spør mest om:

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. Tabellen nedenfor viser hvor hver funksjon står.

Den strategiske forskjellen fra GHEC: fremforge behandler HTTPS+GCM som hovedveien, fordi MFA naturlig følger med gjennom IdP-en ved hver fornyelse av tokenet; SSH er et tilvalg per organisasjon, fordi IP-håndhevingen der er svakere i denne arkitekturen. For de fleste sikkerhetskrav fra virksomheter («MFA ved hver push», «begrens etter IP hvor utviklere kan pushe fra») er standarden med HTTPS+GCM klart sterkere enn standarden med SSH-nøkler som GHEC har arvet fra GitHubs historie.

Steg 1: Migrering av repository og historikk

fremforge kjører upstream-Forgejo, som har et innebygd importverktøy for GitHub-repositoryer. Importverktøyet kopierer hele Git-historikken, issues, pull requests, kommentarer, etiketter, milepæler, wiki-innhold og utgivelser, ikke bare standardbranchen.

Med det innebygde importverktøyet (via webgrensesnittet)

Fra administrasjonsgrensesnittet i fremforge for organisasjonen din:

1. Klikk + → Ny migrasjon.
2. Velg GitHub som kilde.
3. Lim inn URL-en til GitHub-repositoryet (f.eks. https://github.com/acme/backend).
4. Lim inn det personlige tilgangstokenet ditt for GitHub. Tokenet brukes bare til denne importen og lagres ikke etter at importen er ferdig.
5. Kryss av for innholdstypene som skal importeres: Wiki, Issues, Pull requests, Utgivelser, Etiketter, Milepæler.
6. Velg målorganisasjon og navn på repositoryet i fremforge. Standardverdiene speiler GitHub-kilden.
7. Klikk Migrer repository.

Importverktøyet kjører i bakgrunnen. For et typisk repository på 100–500 MB med middels mye historikk for issues og PR-er kan du regne med 2–10 minutter. En fremdriftsindikator i administrasjonsgrensesnittet viser hvilket steg den er på (kloning av Git-historikk, import av issues, import av PR-er, import av utgivelser).

Med API-et (skriptbart)

For massemigreringer skripter du importen mot fremforge-API-et. Endepunktene for migrering, repositoryer, issues og PR-er er Forgejos egen API-flate, som fremforge eksponerer uendret på frem.sh/_app/api/v1/...; de er ikke dokumentert for seg i fremforges OpenAPI-spesifikasjon (som bare dekker tilleggene i fremforges kontrollplan: brukere, policy, funn, eksporter, fullmakter). For en oppdatert referanse til Forgejos egne endepunkter, se docs.frem.sh/api/openapi.yaml eller upstream-Forgejos OpenAPI-dokumentasjon på docs.codeberg.org/api/; fremforge hoster ikke Forgejos Swagger UI i produksjon (med vilje slått av, fordi det er et kjent mål for rekognosering). Alle endepunktene nedenfor er vanlige Forgejo/Gitea-API-er.

# Build the JSON body via jq so the token is JSON-string-escaped safely
# (a token containing `"` or `\` would otherwise break the body or
# corrupt your migration auth).
jq -nc \
  --arg clone_addr "https://github.com/acme/backend.git" \
  --arg auth_token "$GITHUB_TOKEN" \
  --arg repo_owner "acme" \
  --arg repo_name  "backend" \
  '{clone_addr: $clone_addr, auth_token: $auth_token,
    service: "github", 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 @-

Kjør parallelt på tvers av repositoryer med GNU parallel eller et lite styringsskript. Begrens til 3–5 samtidige importer for å unngå å mette verken GitHubs frekvensgrense for PAT eller din egen båndbredde.

Hva importverktøyet importerer, og hva det ikke importerer

Importeres riktig:

• Alle brancher og tagger, med full commit-historikk.
• Issues med titler, tekst, kommentarer, etiketter, milepæler og ansvarlige (koblet via e-post der brukeren finnes i fremforge).
• Pull requests med gjennomgangskommentarer, merge-status og årsak til lukking. Åpne PR-er blir åpne PR-er; lukkede PR-er blir lukket.
• Utgivelser med binære vedlegg (flyttet til fremforges LFS-lagring i EU).
• Wiki-sider.

Importeres ikke:

• Historikk for GitHub Actions-workflow-kjøringer. Tidligere kjøringer blir værende på GitHub; nye kjøringer starter på nytt i fremforge.
• Verdier i secrets og miljøvariabler; disse legger du inn på nytt (se steg 2).
• Tredjepartsintegrasjoner som er satt opp på GitHub. De må kobles til på nytt (se steg 5).
• GitHub Projects (classic eller Projects v2). Forgejo har ingen tilsvarende funksjon én til én; enkelt innhold fra prosjekttavler kan gjenskapes manuelt eller via Projects-funksjonen i fremforge (fase 1.5).
• Dependabot-varsler. Skanningen av avhengigheter i fremforge kjører uavhengig med Trivy/osv-scanner og lager sine egne funn.
• Sikkerhetsmeldinger (security advisories) for repositoryer. Opprett de du vil ha på nytt under Sikkerhet › Rapporter › Sårbarhetsvarsler (Sikkerhetsvarsler), eller via API-et med data fra GitHubs GET /repos/{owner}/{repo}/security-advisories; publiserte sikkerhetsmeldinger får en ny FFSA--ID, så behold GHSA-ID-en i referansene.
• GitHub Discussions. Ingen motsvarighet i Forgejo i dag.
• Varslingsinnstillinger per bruker. Medlemmene abonnerer på nytt i fremforge.

Store repositoryer

Hvis repositoryet ditt er over 2 GB eller LFS-samlingen er over 5 GB, kan importverktøyet i webgrensesnittet få tidsavbrudd. Forgejos /repos/migrate-endepunkt har ingen innstilling for tidsavbrudd per kall, så den anbefalte reserveløsningen er å ta en direkte speilkloning med Git lokalt og kjøre git push --mirror til et tomt fremforge-repository som er opprettet på forhånd:

# Clone the GitHub repo bare with full history
git clone --mirror https://github.com/acme/backend.git
cd backend.git

# If the repo uses LFS, fetch all LFS content
git lfs fetch --all

# Create an empty repo on fremforge (via admin UI or API), then:
git remote set-url origin https://frem.sh/acme/backend.git
git push --mirror
git lfs push --all origin

Med denne veien følger ikke historikken for issues og PR-er med. Importer den separat via Forgejos migrerings-API (POST /api/v1/repos/migrate, se det kanoniske curl-eksempelet øverst på denne siden) med "wiki": false, "issues": true, "pull_requests": true, og rett forespørselen mot URL-en til fremforge-repositoryet som allerede er pushet, slik at bare metadataene hentes fra GitHub.

Skanningen etter secrets i pre-receive sperrer denne pushen. fremforge kjører gitleaks som en pre-receive-hook i Forgejo ved hver push, også ved --mirror som over. Hvis de historiske commitene dine inneholder ekte secrets (lekkede AWS-nøkler, utløpte Stripe-tokener, innebygde private nøkler), blir pushen avvist med SHA-ene til de aktuelle commitene skrevet ut, og hele speiloperasjonen feiler atomisk. Det er med vilje: å importere en secret fra offentlig historikk til fremforge roterer den ikke i det stille hos upstream-leverandøren, så den trygge veien er å rense før import. To måter å komme videre på:

1. Rens historikken først med git-filter-repo (anbefalt) eller BFG Repo-Cleaner, og push på nytt. Gi beskjed til eieren av secreten om at historikken hos upstream-leverandøren også lekker, uansett hva du gjør på målsiden; roter den lekkede legitimasjonen ved kilden.
2. Be om et engangsunntak fra support@frem.sh for kjente, tilbakekalte secrets i arkivert historikk. Unntaket logges, revideres og knyttes til en skriftlig bekreftelse på at secretene allerede er rotert.

Push main først, så LFS-pushen blir nyttig. Fordi git push --mirror er atomisk mot gitleaks (alle refs i én transaksjon; én avvisning = tomt speil = LFS-pushen har ingenting å pushe til), lønner det seg å pushe én branch først for å bekrefte reglene før du pusher alle refs. Mellom git remote set-url og git push --mirror:

git push origin main --force-with-lease

Hvis main går gjennom, går nesten alltid resten av refs gjennom også (gitleaks-reglene er basert på innhold, ikke på branch). Hvis main avvises, renser du eller ber om unntak før du prøver speilingen igjen; det er ingen vits i å pushe andre refs mens commiten med secreten på main fortsatt er aktiv.

Hooken bruker de samme gitleaks-reglene som beskytter alle fremforge-repositoryer, og er ikke en sjekk spesielt for migrering. Kjør pre-migration-check.sh før du begynner; den viser de samme funnene som hooken ville fanget, så du kan rense før migreringsvinduet åpner.

LFS-lagringskvote og kapasitet for store repositoryer

git lfs push --all origin skriver objekter inn i LFS-kvoten til fremforge-organisasjonen din. Planlegg kvotene:

To praktiske grenser ligger under kvoten i planen:

• Størrelsen på det rå git-repositoryet. Hvis repositoryets bare .git (etter git gc --aggressive) er over ca. 5 GiB, kontakter du support@frem.sh før migreringen, så vi kan bekrefte at det er nok kapasitet til repositoryet ditt.
• Svært store LFS-pusher. git lfs push av mer enn ca. 100 GiB i én økt må kanskje deles opp i omganger på ≤50 GiB for å unngå struping fra frekvensgrensen. Feilen er HTTP 503 med X-Reserved: ratelimit i svaret; vent 60 s og fortsett; LFS kan gjenopptas.

Hvis du er usikker på hvor stor LFS-samlingen vil bli, kjører du git lfs ls-files --size --all | awk '{s+=$2} END {print s/1024/1024/1024 " GiB"}' mot kilderepositoryet før du starter speilpushen.

Steg 2: Secrets og miljøvariabler

GitHub lagrer secrets på organisasjons-, miljø- og repositorynivå. fremforge bruker de samme tre nivåene.

Viktig: verdier i secrets kan ikke eksporteres fra GitHub. GitHubs API returnerer navnene på secrets, men aldri verdiene. Enten kjenner du verdien (roter ved migreringen, anbefalt), eller du henter den fra kilden der du administrerer secrets (passordbehandler, vault, verktøy for CI-orkestrering).

Legge inn secrets på nytt

For hver secret avgjør du:

• Er dette en langlivet legitimasjon som uansett bør erstattes med OIDC-føderasjon? I så fall setter du opp OIDC-føderasjon til T Cloud Public (se steg 3) og sletter secreten i stedet for å migrere den.
• Er dette en API-nøkkel eller tjenestelegitimasjon hos en tredjepart uten OIDC-alternativ? Roter legitimasjonen ved kilden, og sett den nye verdien i fremforge.
• Er dette en kryptografisk nøkkel som brukes i bygg? Roter den, og sett den i fremforge.

Sett secrets på riktig nivå i administrasjonsgrensesnittet i fremforge:

• Organisasjons-secrets, tilgjengelige for alle repositoryer i organisasjonen. Settes under Organisasjonsadministrasjon → Secrets (frem.sh/<org>/_admin/secrets).
• Miljø-secrets, bare tilgjengelige i det navngitte miljøet (f.eks. production, staging). Settes under Organisasjonsadministrasjon → Miljøer → <env> → Miljø-secrets.
• Repository-secrets, avgrenset til ett repository. Settes under Repository → Innstillinger → Actions → Secrets.

Miljøvariabler (konfigurasjon som ikke er hemmelig)

GitHub Actions støtter env: og vars: på workflow-, jobb- og stegnivå. fremforge Actions støtter samme syntaks; innebygde variabler trenger ingen migrering.

For variabler på organisasjons- og repositorynivå (vars:-konteksten i GitHub) har fremforge de samme nivåene. Settes under Innstillinger → Actions → Variabler i Forgejo-innstillingene til organisasjonen eller repositoryet.

Steg 3: Tilpasning av Actions-workflower

Forgejo Actions er i stor grad kompatibelt med GitHub Actions, men ikke identisk bit for bit. En workflow som kjører på GitHub, kjører som regel på fremforge med to eller tre bestemte justeringer. Kompatibilitetsmatrisen for de 20 mest brukte Marketplace-actions på docs.frem.sh/marketplace-compat dokumenterer hvilke actions som virker som de er, hvilke som trenger en innpakning, og hvilke som ikke har noen motsvarighet i fremforge.

Endringer som gjelder nesten alle workflower

1. uses-referanser kan bli stående som actions/*@version for de store GitHub-actions.

fremforges runner løser opp uses:-direktiver gjennom fremverks speil som bare ligger i EU, på https://frem.sh/<owner>/<repo> (én speilorganisasjon per upstream-utgiver, så actions/checkout løses opp til frem.sh/actions/checkout), og runner-VM-ene har ikke direkte utgående trafikk til github.com når jobben starter (DPA vedlegg A.6). Dette virker for actions/checkout, actions/setup-node, actions/setup-go, actions/setup-python, actions/setup-java, actions/cache, actions/upload-artifact, actions/download-artifact og resten av de offisielle actions/* som allerede er speilet. uses:-linjene dine trenger ingen endring for speilede actions; hvis en referanse mangler, se Vanlige fallgruver nedenfor.

2. Semantikken til ${{ secrets.GITHUB_TOKEN }} er litt annerledes.

GitHub leverer et automatisk token med hver workflow, med avgrensede tillatelser til repositoryet som kaller. Forgejo leverer det tilsvarende som ${{ secrets.FORGEJO_TOKEN }}, og ${{ secrets.GITHUB_TOKEN }} er et alias for det samme tokenet, så de fleste workflower virker uten videre. Bruk ett av disse to navnene i stedet for det eldre ${{ secrets.GITEA_TOKEN }}. Siden 21. oktober 2026 setter de hostede runnerne (forgejo-runner 13) ikke lenger noen GITEA_*-miljøvariabler, så erstatt GITEA_ACTIONS med FORGEJO_ACTIONS eller GITHUB_ACTIONS, og GITEA_ACTIONS_RUNNER_VERSION med FORGEJO_ACTIONS_RUNNER_VERSION. Hvis en workflow forventer bestemt oppførsel fra GitHub-API-et bak det tokenet (f.eks. å utløse GitHubs Checks-API), må den tilpasses. For Forgejos egne check runs ligger det tilsvarende API-et på frem.sh/api/v1/repos/{owner}/{repo}/check-runs.

3. Actions som kaller GitHubs REST-API direkte, må tilpasses.

Hvis en workflow bruker curl https://api.github.com/... eller octokit for å kalle GitHubs REST-API direkte, må disse kallene rettes mot https://frem.sh/_app/api/v1/... via fremforge-API-et (i stor grad GitHub-kompatibelt på REST-flaten). Se OpenAPI-spesifikasjonen.

4. Standardskallet for steg er annerledes.

Standardskallet i Forgejo-runneren er bash med POSIX-flagg. Standardene i GitHubs runner er litt forskjellige mellom Linux og Windows/macOS. Hvis workflowen din avhenger av bestemt oppførsel ved sitering i skallet, setter du eksplisitt shell: bash (Linux), shell: pwsh (Windows), shell: sh (bare POSIX).

Endringer som gjelder noen workflower

if: github.*-konteksten.

Forgejo Actions tilbyr github.*-kontekstvariabler med samme navn som GitHub Actions. Nesten alle if-uttrykk kan flyttes uendret. Spesialtilfellene gjelder GitHub-spesifikke metadata (f.eks. github.event.pull_request.auto_merge), der Forgejo kanskje ikke eksponerer nøyaktig samme egenskap.

Marketplace-actions som er spesifikke for GitHub-API-et.

Eksempler: peter-evans/create-pull-request, marocchino/sticky-pull-request-comment, nwtgck/actions-netlify. De fleste av disse virker rett ut av boksen, fordi fremforges REST-flate godtar API-kallene deres. Noen få trenger små rettelser. Topp 20-matrisen dokumenterer konkrete omveier.

Workflower som må skrives om

Hvis workflowen din bruker funksjoner som er spesifikke for GitHub Enterprise (API-et for rulesets i organisasjoner, GHES-spesifikke endepunkter for målinger, API-et for Copilot Extensions, GitHub Packages utover npm/Docker/Maven), må disse funksjonene erstattes. Som regel er erstatningen innebygd i fremforge:

• Rulesets i organisasjoner → policy på organisasjonsnivå i fremforge (Organisasjonsadministrasjon → Sikkerhet → Policyer → Regler for repositoryer).
• GitHub Packages → fremforges pakkeregister (støtter npm, Maven, Docker, NuGet, PyPI, RubyGems, Composer, Go).
• Copilot Extensions → bevisst utenfor fremforges omfang (se innlegget om AI-holdning på www.frem.sh).

Steg 4: Ny registrering av SSH-nøkler

Offentlige SSH-nøkler hører til den enkelte brukeren og migreres ikke. Hver utvikler legger til sin offentlige SSH-nøkkel på fremforge-kontoen sin:

1. Logg inn på fremforge.
2. Innstillinger → SSH- / GPG-nøkler → Legg til nøkkel.
3. Lim inn den offentlige nøkkelen (~/.ssh/id_ed25519.pub eller tilsvarende).

Fingeravtrykkene for vertsnøklene til frem.sh er publisert på www.frem.sh/ssh-fingerprints. Utviklerne bør kontrollere dem ved første SSH-tilkobling for å hindre et ubemerket MITM-angrep. Fingeravtrykket vises ved første tilkobling; utviklerne sammenligner med tillitssiden, bekrefter, og nøkkelen låses for senere tilkoblinger.

For team som bruker SSH-sertifikatutstedere, støtter fremforge oppsett av klarerte CA-er direkte fra organisasjonens administrasjonsgrensesnitt på <your-org>/_admin/auth-policy: seksjonen for SSH CA ligger under bryteren «Allow SSH protocol» (lagt inn i Autentiseringspolicy 2026-05-26; den frittstående /admin/ssh-ca/ omdirigerer hit). Lim inn CA-ens offentlige OpenSSH-nøkkel, velg en principal-policy (brukernavn / e-post / ugjennomsiktig), og håndhev eventuelt «require cert auth», slik at vanlig innlogging med offentlig nøkkel avvises. Se seksjonen om SSH-sertifikatutsteder i veiledningen for autentiseringspolicy for hele oppsettet, inkludert eksempler på integrasjon med Smallstep / Vault. Hver bruker som autentiserer seg med et sertifikat CA-en har utstedt, slippes inn med tillatelsene til den tilsvarende fremforge-kontoen.

For team der SSO håndheves (sso_required = true på organisasjonsnivå), validerer SSH-autentiseringen i tillegg et OIDC-refresh-token mot tenantens IdP ved hver tilkobling (bufret i 15 minutter). Det betyr at deprovisjonering av en bruker i IdP-en blokkerer SSH-tilgangen innen 15 minutter, selv om SSH-nøkkelen fortsatt er registrert i fremforge. Ingen egen opprydding av nøkler trengs.

Steg 5: Ny tilkobling av tredjepartsintegrasjoner

Integrasjoner som er satt opp på GitHub (webhooker, CI-varsler til Slack/Teams, deploy-hooker til Vercel/Netlify, synkronisering med issue-trackere som Jira/Linear, verktøy for kodegjennomgang som Sourcegraph eller Graphite), migreres ikke automatisk. Hver av dem må kobles til på nytt.

Webhooker

GitHub-webhooker ligger under Repository → Settings → Webhooks. Webhooker i fremforge ligger på samme sted i administrasjonsgrensesnittet. Formen på webhook-nyttelasten er i stor grad kompatibel; de viktigste forskjellene:

• Headeren X-GitHub-Event på GitHub er X-Forgejo-Event (eller X-Gitea-Event for mottakere som er kompatible med Gitea) i fremforge. De fleste generiske webhook-mottakere godtar begge.
• Leveringsidentifikatoren er X-Gitea-Delivery + X-Hook-UUID (tilsvarer GitHubs X-GitHub-Delivery). Begge finnes i hver webhook fremforge sender, og de fleste mottakere bruker en av dem som nøkkel.
• Hendelsestypene er et nært supersett av GitHubs kjernehendelser. push, pull_request, pull_request_review, issues, issue_comment, release, create, delete, fork og star finnes alle.
• Signaturheaderen er X-Forgejo-Signature (HMAC-SHA256 med webhook-secreten din).

For mottakere som er skrevet mot GitHubs API (integrasjoner med Slack, Discord, PagerDuty), finnes det to alternativer:

1. Sett opp mottakeren til å bruke sin egen Forgejo-integrasjon. Slacks Forgejo-integrasjon, Discords Forgejo-webhook-mål osv. finnes som regel og er den ryddigste veien.
2. Tilpass webhooken på mottakersiden. Hvis mottakeren er en egen intern tjeneste, legger du til håndtering av Forgejo-hendelser ved siden av håndteringen av GitHub-hendelser. Som regel en liten endring.

CI-integrasjoner (CircleCI, TravisCI, Jenkins)

Hvis du kjører CI utenfor forgen (CircleCI, ekstern Jenkins, Buildkite), er migreringen enkel: pek disse CI-systemene mot repositoryer i fremforge i stedet for repositoryer i GitHub. De fleste eksterne CI-systemer støtter Forgejo/Gitea som kilde; endringen gjøres i CI-systemet, ikke i fremforge.

De fleste team som migrerer til fremforge, benytter anledningen til å samle seg om fremforges hostede runnere og legge ned den eksterne CI-en. Runner-minutter er inkludert i den faste prisen per bruker. Se TCO-innlegget på fremverk-bloggen for regnestykket.

Utrullingsmål (Vercel, Netlify, Cloudflare Pages)

Hver tjeneste kobles til fremforge på nytt, enten via innebygd støtte (Vercel og Netlify har integrasjoner med Forgejo/Gitea som git-kilde) eller via en generisk deploy-hook ved Git-push. Dokumenter de nye webhook-URL-ene dine og oppdater dem i dashbordet til hver tjeneste.

Synkronisering med issue-trackere (Jira, Linear, Zendesk)

Hvis synkroniseringen med issue-trackeren er basert på Git-commits (kobler commits til issues via ID), fortsetter den å virke. Commit-SHA-ene bevares gjennom migreringen. Hvis synkroniseringen er basert på GitHub-API-et (lytter etter PR-hendelser, spør etter GitHub-issues), setter du den opp mot webhooker i fremforge eller slår den av.

Steg 6: DNS og egne domener (hvis aktuelt)

fremforge leverer repositoryinnhold bare på frem.sh/<org>/<repo>. Egne Git-domener som kunden eier, støttes ikke; det finnes ingen motsvarighet til funksjonen «custom hostname» i GitHub Enterprise Server, der TLS termineres med ditt sertifikat på git.company.com. To konsekvenser verdt å si tydelig:

Forfengelighets-CNAME uten TLS

En forfengelighets-CNAME i kundens DNS (f.eks. intern git.company.com CNAME → frem.sh) er teknisk mulig, men TLS-sertifikatet som leveres, er alltid fremforges *.frem.sh-sertifikat, IKKE et *.company.com-sertifikat. En nettleser som går til https://git.company.com/..., vil vise en advarsel om navnefeil, med mindre kunden også skaffer og leverer sitt eget sertifikat via sin egen omvendte proxy foran. Det er et prosjekt på kundens side: fremforge terminerer ikke TLS for forfengelighetsvertsnavn, godtar ikke sertifikater fra kunder og kjører ikke noe SNI-lag med flere sertifikater.

Anbefalt vei for kunder som flytter fra GitHub Enterprise Server: ta i bruk URL-mønsteret frem.sh/<org>/* direkte. Oppdater interne lenker, CI-konfigurasjoner og dokumentasjon til de nye URL-ene. Veien med forfengelighets-CNAME og kundens eget sertifikat gir driftsgjeld (fornyelse av sertifikater, drift av proxy) og er ikke en konfigurasjon fremforge støtter.

Ta med en Enterprise-on-Demand-kontrakt hvis innkjøpskravene dine krever en SLA for et eget domene. Det åpner for en samtale om et eget kantlag med terminering av kundens sertifikat, men det er utenfor omfanget av selvbetjeningsnivået.

Hva som migreres, og hva som ikke migreres

Denne seksjonen lister hvilke GitHub-artefakter som går gjennom migreringen, og med hvilken nøyaktighet. Bruk den som sjekkliste for avstemming før migreringen.

Gjenopptakelse

Forgejos /repos/migrate-endepunkt kan ikke gjenopptas. Hvis kallet feiler underveis (nettverksbrudd, frekvensgrense i kilde-API-et osv.), blir det delvis importerte repositoryet liggende i en inkonsistent tilstand. Slik retter du opp:

1. Slett det delvise repositoryet via Innstillinger → Slett i administrasjonsgrensesnittet i fremforge.
2. Send migreringskallet på nytt med en gang. Hvis det returnerer 422 med repository already exists, venter du 5 sekunder og prøver igjen; dette er replikeringsforsinkelse i RDS på lesereplikaen, ikke en gravstein-syklus i Forgejo.
3. Hvis andre forsøk feiler på samme måte, bruker du et nytt repositorynavn.

For repositoryer der en ny import er kostbar (store LFS-mengder, mange issues), bruker du reserveløsningen med lokalt speil som er beskrevet under «Store repositoryer»; git push --mirror kan naturlig gjenopptas, fordi git selv håndterer nettverksbrudd på en god måte.

Kontroll etter migreringen

Utover listen «kontroller og fas ut» i steg 7 nedenfor er dette kontrollene etter migreringen som kunder oftest glemmer:

• Sammenlign antall commits. git rev-list --count HEAD i GitHub-klonen og i fremforge-klonen. Tallene må være nøyaktig like.
• Sammenlign listen over brancher. git branch -r | sort på hver side, og diff resultatet. Gamle refs/pull/*-refs fra GitHub migreres ikke (Forgejo nummererer PR-er i sitt eget ref-rom); alt annet skal stemme.
• Sammenlign listen over tagger. git tag --sort=v:refname på hver side; listene skal være identiske.
• Sammenlign antall LFS-pekere. git lfs ls-files | wc -l; tallene skal være nøyaktig like. Hvis de ikke er det, kjører du git lfs fetch --all && git lfs push --all origin mot fremforge-remoten.
• Antall issues / PR-er og nummerering. gh issue list --limit 5000 --state all --json number | jq length på GitHub mot fremforge /api/v1/repos/<org>/<repo>/issues?state=all (med sideinndeling). Løkke med sideinndeling for fremforge: n=0; for p in $(seq 1 200); do c=$(curl -fsS "https://frem.sh/api/v1/repos/<org>/<repo>/issues?state=all&page=$p&limit=50" -H "Authorization: Bearer $T" | jq length); [ "$c" = 0 ] && break; n=$((n + c)); done; echo $n. Nummereringen bevares.
• Grønn CI. Utløs et bygg som ikke endrer noe, på main, og kontroller at Forgejo Actions-kjøringen når success. Det fanger opp hull i uses:-speilene (den vanligste CI-feilen etter en migrering).

Hvis noen av disse viser avvik, fases ikke GitHub-kilden ut før avviket er løst.

Steg 7: Kontroller og fas ut

Etter migreringen:

1. Klon det migrerte repositoryet fra fremforge, kjør bygget og kontroller at testene går gjennom.
2. Åpne en test-PR for å kontrollere at pre-receive-skanneren etter secrets, avhengighetsskanneren og verifiseringen av signerte commits er aktive som forventet.
3. Sjekk visningen Funn i administrasjonsgrensesnittet for å bekrefte at det ikke er overraskende skanneresultater i den migrerte historikken.
4. Kontroller at webhooker leveres riktig via Innstillinger → Webhooks → Nylige leveringer.
5. Kontroller at SSO-innlogging virker for hver bruker som skal ha tilgang til repositoryet.
6. Oppdater dokumentasjon og interne wikier så de peker til de nye repository-URL-ene.
7. Etter 30 dager med vellykket drift i fremforge setter du GitHub-repositoryene til arkivert tilstand. Ikke slett dem; behold dem av hensyn til revisjonshistorikken.

Tilbakerulling (delvis, planlegg deretter)

Migreringen kan delvis reverseres, ikke fullt ut. Vær ærlig om hva som kan og ikke kan føres tilbake, før du flytter produksjonstrafikk.

Dette KAN gjenopprettes ved tilbakerulling:

1. Git-historikk: git push --mirror fra en lokal fremforge-klone tilbake til GitHub-repositoryet gjenoppretter brancher, tagger og commits.
2. Webhooker og integrasjoner: slå dem på igjen på GitHub-siden; du må manuelt oppdatere mål-URL-ene for webhookene tilbake til endepunkter hos GitHub.

Dette kan IKKE gjenopprettes med full nøyaktighet:

3. Issues, PR-er og kommentarer som er opprettet etter migreringen: fremforges Organisasjonsadministrasjon → Dataeksport lager en JSON-dump, men GitHubs import-API bruker et annet skjema, så en ny import er en manuell kartleggingsjobb. Issue-numrene vil ikke stemme; kryssreferanser i commit-meldinger vil peke ut i løse luften. Forfatterskap krever at hver bidragsyter har en GitHub-konto igjen. Reaksjoner, gjennomgangstråder og kommentarer festet til linjer overlever som regel ikke turen frem og tilbake.
4. CI-historikk og Actions-logger som er laget i fremforge: kan ikke eksporteres i noe tilsvarende format.
5. fremforge-spesifikke funn: avvisninger fra skanningen etter secrets, resultater fra skanningen av avhengigheter og attesteringer av signerte commits som er laget i fremforge, har ingen motsvarighet i GitHub å importere til.

Behandle migreringen som en enveisdør for produksjonsbruk. Kjør et pilotprosjekt med ett repository som ikke er kritisk, først; kontroller at CI, webhooker og SSO virker; migrer deretter resten i omganger. Formuleringen «kan reverseres innen 30 dager» gjelder bare tilbakerulling av git-historikken; ikke stol på den for full gjenoppretting av samarbeidstilstanden.

Vanlige fallgruver

LFS-objekter er ikke synlige etter migreringen.

Importverktøyet i webgrensesnittet håndterer LFS automatisk for små samlinger (<5 GB). For større samlinger kjører du git lfs fetch --all på en lokal speilklone og git lfs push --all origin til fremforge manuelt.

Actions-workflower feiler ved første kjøring med «action not found».

Speilene på https://frem.sh/<owner>/<repo> (se oppløsning av Actions over) dekker standardsettet actions/* og ti andre utgiverorganisasjoner. En uses:-referanse som feiler, betyr at actionen ikke er speilet ennå. Send en henvendelse til support@frem.sh med den manglende referansen, så plukkes den opp i neste speilrunde; eller lås til en tidligere oppløst versjon som allerede er bufret.

Gjennomgangskommentarer i PR-er importeres som vanlige PR-kommentarer.

Forgejos importverktøy gjør gjennomgangskommentarer i PR-er om til vanlige PR-kommentarer, ikke til gjennomgangskommentarer på linjenivå. Dette er en begrensning i datamodellen på tvers av forger; kommentarer direkte i koden mister sammenhengen med linjen de var knyttet til. Omvei: for repositoryer der kommentarene i koden er viktige, eksporterer du dem til en egen datafil via GitHubs API før migreringen og tar vare på dem som et arkivvedlegg på den migrerte PR-en.

Brukere kobles ikke automatisk.

Importverktøyet kobler GitHub-brukere via e-postadresse. Brukere der e-postadressen i GitHub ikke stemmer med e-postadressen i fremforge (f.eks. privat e-post i GitHub, jobb-e-post i fremforge), vises som «Unknown user» på importerte issues. Enten kobler du dem på forhånd ved å legge til e-postadressen fra GitHub som sekundær e-postadresse på fremforge-kontoen før importen, eller du godtar visningen «Unknown user» og støtter deg på det opprinnelige forfatterskapet som er synlig i commit-historikken.

Få hjelp

Hvis noe i denne veiledningen ikke virker for ditt oppsett:

• Send e-post til support@frem.sh med en emnelinje som starter med MIGRATION, GITHUB -, og en beskrivelse av hvor du sto fast.
• Hvis du er på planen for kunder som er tidlig ute, har du direkte kontakt med teamet som bygger fremforge, for hjelp med migreringen, uten ekstra kostnad.

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