Migrer til fremforge fra GitHub

Denne vejledning fører et typisk GitHub-team gennem en migrering til fremforge. Den dækker GitHub.com, GitHub Enterprise Cloud (GHEC) og GitHub Enterprise Server (GHES). Læs den hele igennem, før du går i gang. Overraskelser midt i en migrering er dyre.

Er du ikke klar til at flytte alt på én gang? Brug fremforge ved siden af GitHub viser, hvordan du spejler repositories, så fremforge scanner dem, og hvordan du uploader SBOM’er fra GitHub Actions, mens flytningen står på.

Hvis du endnu ikke har kørt tjeklisten før migrering mod din nuværende GitHub-tenant, så gør det først. Den finder store repositories, brug af LFS, afhængigheder af Marketplace-actions og tredjepartsintegrationer, der kræver særlig opmærksomhed.

Før du starter

Det skal du have på din side:

• En konto med ejerrollen i den GitHub-organisation, du migrerer fra.
• Et personligt adgangstoken på GitHub med scopes repo, admin:org, workflow og admin:public_key (klassisk PAT) eller det tilsvarende fine-grained token.
• Administratoradgang til den fremforge-organisation, du migrerer til (organisationen oprettes ved tilmelding).
• Til migrering af Actions: en oversigt over de GitHub Marketplace-actions, du bruger i dag, og deres versioner.

Det anbefaler vi:

• Stop nye PR’er og merges til de hovedbranches, du migrerer, i migreringsvinduet. Samtidige skrivninger under migreringen giver besvær med afstemning, som du ikke har brug for.
• Kør først migreringen mod en testorganisation på fremforge, der ikke er produktion, hvis du er i tvivl om, hvordan dine workflows skal tilpasses. Den gratis prøveperiode på 30 dage er lavet til præcis det.
• Migrer ét repository hele vejen, og bekræft, at det bygger rent, før du massemigrerer resten.

Tidsestimat (planlægningsintervaller, ikke løfter):

• Et enkelt lille repository (≤100 MB, ingen LFS, simple Actions): 15-30 minutters aktivt arbejde plus verifikation af CI.
• Et mellemstort repository (≤1 GB, noget LFS, moderat komplekse Actions): 1-2 timer inklusive tilpasning af workflows.
• En massemigrering af 20-50 repositories: 1-2 ingeniørdage fordelt over en uge, hvor det meste går med at tilpasse Actions og ikke med selve migreringen af repos.

Intervallerne bygger på en gennemgang af dokumentationen holdt op mod Forgejo upstreams ydeevne og 2 interne fremverk-migreringer før lanceringen; de faktiske tider vil blive kalibreret ud fra vores første 5 kundemigreringer. De er hjælp til planlægning, ikke kontraktlige SLA’er. Migreringstiden i praksis afhænger af: (a) antal repos og samlet LFS-mængde; (b) kompleksiteten af Actions og antallet af uses:-referencer, der skal skrives om til fremforges runner-spejl; (c) hvor stort et team der kan løfte verifikationen. Hvis du migrerer mere end 50 repos eller bruger Actions i ikke-trivielt omfang, så planlæg med mindst 2× den øvre grænse som buffer, og kør først en pilot med ét repository.

Sammenligning af funktioner

Det, fremforge leverer i dag, sammenlignet med GitHub Enterprise Cloud, med fokus på den del om sikkerhed og godkendelse, som kunderne spørger mest til:

fremforge giver som standard nye organisationer Git-adgang kun over HTTPS (SSH slået fra som standard siden 2026-05-22) med den forhåndsregistrerede OAuth-app til Git Credential Manager: udviklere får MFA via organisationens IdP, hver gang tokenet fornyes ved push. Tabellen nedenfor viser, hvor hver funktion står.

Den strategiske forskel fra GHEC: fremforge behandler HTTPS+GCM som den primære vej, fordi MFA naturligt følger med gennem IdP’en ved hver fornyelse af tokenet; SSH slås til pr. organisation, fordi håndhævelsen af IP er strukturelt svagere på denne stak. For de fleste sikkerhedskrav i virksomheder (“MFA ved hvert push”, “begræns, hvilke IP-adresser udviklere kan pushe fra”) er HTTPS+GCM-standarden klart stærkere end den SSH-nøgle-standard, GHEC har arvet fra GitHubs historik.

Trin 1: Migrering af repository og historik

fremforge kører Forgejo fra upstream, som har en indbygget importør til GitHub-repositories. Importøren kopierer hele Git-historikken, issues, pull requests, kommentarer, labels, milepæle, wikiindhold og releases, ikke kun standardbranchen.

Med den indbyggede importør (via brugerfladen)

Fra fremforges administration for din organisation:

1. Klik på + → Ny migration.
2. Vælg GitHub som kilde.
3. Indsæt URL’en til GitHub-repositoryet (f.eks. https://github.com/acme/backend).
4. Indsæt dit personlige adgangstoken fra GitHub. Tokenet bruges kun til denne import og gemmes ikke, når importen er færdig.
5. Sæt flueben ved de indholdstyper, der skal importeres: Wiki, Issues, Pull requests, Releases, Labels, Milestones.
6. Vælg målorganisation og repository-navn på fremforge. Standardværdierne svarer til kilden på GitHub.
7. Klik på Migrate repository.

Importøren kører i baggrunden. For et typisk repository på 100-500 MB med en moderat historik af issues og PR’er kan du regne med 2-10 minutter. En statusindikator i administrationen viser det aktuelle trin (kloning af Git-historik, import af issues, import af PR’er, import af releases).

Med API’et (via scripts)

Ved massemigreringer kan du scripte importen mod fremforges API. Endpoints til migrering, repos, issues og PR’er er Forgejos egen API-overflade, som fremforge udstiller uændret på frem.sh/_app/api/v1/...; de er ikke dokumenteret separat i fremforges OpenAPI-spec (som kun dækker fremforges tilføjelser i kontrolplanet: brugere, politik, fund, eksporter, mandater). Referencen for Forgejos egne endpoints finder du i docs.frem.sh/api/openapi.yaml eller i Forgejos OpenAPI-dokumentation på docs.codeberg.org/api/. fremforge hoster ikke Forgejos Swagger UI i produktion (bevidst slået fra, fordi det er et kendt mål for rekognoscering). Alle endpoints nedenfor er standard-API fra Forgejo/Gitea.

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

Kør flere repositories parallelt med GNU parallel eller et lille driverscript. Begræns til 3-5 samtidige importer, så du hverken mætter GitHubs rate limit for PAT’er eller din egen båndbredde.

Hvad importøren tager med, og hvad den ikke tager med

Importeres korrekt:

• Alle branches og tags med fuld commit-historik.
• Issues med titler, brødtekst, kommentarer, labels, milepæle og tildelte personer (matchet på e-mail, hvor brugeren findes på fremforge).
• Pull requests inklusive review-kommentarer, merge-status og lukkeårsag. Åbne PR’er bliver åbne PR’er; lukkede PR’er er lukkede.
• Releases inklusive binære vedhæftninger (flyttet til fremforges LFS-lager i EU).
• Wikisider.

Importeres ikke:

• Historik over GitHub Actions-workflowkørsler. Tidligere kørsler bliver på GitHub; nye kørsler starter forfra på fremforge.
• Værdier af secrets og miljøvariabler; dem indtaster du igen (se trin 2).
• Tredjepartsintegrationer, der er sat op på GitHub. De skal forbindes igen (se trin 5).
• GitHub Projects (classic eller Projects v2). Forgejo har ikke en 1:1-modsvarighed; enkelt indhold fra projekttavler kan genskabes i hånden eller med fremforges Projects-funktion (fase 1.5).
• Dependabot-alarmer. fremforges afhængighedsscanning kører uafhængigt på Trivy/osv-scanner og giver sine egne fund.
• Sikkerhedsmeddelelser for repositories. Genskab dem, du vil beholde, under Sikkerhed › Rapporter › Sikkerhedsmeddelelser (Sikkerhedsmeddelelser), eller via dens API ud fra GitHubs GET /repos/{owner}/{repo}/security-advisories; offentliggjorte meddelelser får et nyt FFSA--id, så behold GHSA-id’et i referencerne.
• GitHub Discussions. Ingen modsvarighed i Forgejo i dag.
• Notifikationsindstillinger pr. bruger. Medlemmerne abonnerer igen på fremforge.

Store repositories

Hvis dit repository er over 2 GB, eller din LFS-pulje er over 5 GB, kan importøren i brugerfladen løbe ind i en timeout. Forgejos /repos/migrate-endpoint har ingen indstilling for timeout pr. kald, så den anbefalede udvej er at lave en direkte Git-spejlkloning lokalt og køre git push --mirror ind i et tomt fremforge-repository, der er oprettet 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

Ad denne vej kommer historikken for issues og PR’er ikke med. Importer den separat via Forgejos migrate-API (POST /api/v1/repos/migrate; se curl-eksemplet øverst på siden) med "wiki": false, "issues": true, "pull_requests": true, og peg forespørgslen på URL’en til det fremforge-repo, du allerede har pushet til, så kun metadata hentes fra GitHub.

Secret-scanningen i pre-receive vil kontrollere dette push. fremforge kører gitleaks som Forgejo pre-receive-hook ved hvert push, også ved --mirror-varianten ovenfor. Hvis dine historiske commits indeholder rigtige secrets (lækkede AWS-nøgler, udløbne Stripe-tokens, indlejrede private nøgler), bliver pushet afvist med de matchende commit-SHA’er udskrevet, og hele spejloperationen fejler atomisk. Det er med vilje: at importere en secret fra en offentlig historik til fremforge roterer den IKKE i det stille hos upstream-udbyderen, så den sikre vej er at rense først og importere bagefter. To muligheder for at komme videre:

1. Rens historikken først med git-filter-repo (anbefales) eller BFG Repo-Cleaner, og push igen. Gør ejeren af den pågældende secret opmærksom på, at historikken hos upstream-udbyderen også lækker, uanset hvad du gør på destinationen: roter de lækkede legitimationsoplysninger ved kilden.
2. Bed om en engangsundtagelse hos support@frem.sh for secrets, der vides at være tilbagekaldt, i arkiveret historik. Undtagelsen logges, revideres og knyttes til en skriftlig bekræftelse af, at de pågældende secrets allerede er roteret.

Få main igennem først, så LFS-pushet giver mening. Da git push --mirror er atomisk over for gitleaks (alle refs i én transaktion; én afvisning = tomt spejl = LFS-pushet har intet at pushe til), kan det betale sig at pushe en enkelt branch først for at bekræfte reglerne, før du pusher alle refs på én gang. Mellem git remote set-url og git push --mirror:

git push origin main --force-with-lease

Hvis main går igennem, går resten af refs næsten altid også igennem (gitleaks-reglerne ser på indhold, ikke på branches). Hvis main afvises, så rens eller bed om en undtagelse, før du prøver spejlingen igen; der er ingen grund til at pushe andre refs, så længe committen med secret’en på main stadig er der.

Hooken bruger de samme gitleaks-regler, som beskytter alle fremforge-repos; den er ikke et særligt tjek for migreringer. Kør pre-migration-check.sh, før du starter; det finder de samme fund, som hooken ville fange, så du kan rense, før migreringsvinduet åbner.

LFS-lagerkvote og kapacitet til store repos

git lfs push --all origin skriver objekter ind i din fremforge-tenants LFS-kvote. Kvoter pr. plan:

Under plankvoten ligger to praktiske grænser:

• Størrelse på det bare Git-repo. Hvis repoets bare .git (efter git gc --aggressive) er over ca. 5 GiB, så kontakt support@frem.sh før migreringen, så vi kan bekræfte, at der er plads til dit repo.
• Meget store LFS-push. git lfs push af mere end ca. 100 GiB i én session skal måske deles op i portioner på ≤50 GiB for at undgå neddrosling. Fejlen ser ud som HTTP 503 med X-Reserved: ratelimit i svaret: vent 60 s, og fortsæt; LFS kan genoptages.

Hvis du ikke er sikker på, hvor stor LFS-puljen bliver, så kør git lfs ls-files --size --all | awk '{s+=$2} END {print s/1024/1024/1024 " GiB"}' mod kilderepoet, før du starter spejl-pushet.

Trin 2: Secrets og miljøvariabler

GitHub gemmer secrets på organisations-, miljø- og repository-niveau. fremforge bruger de samme tre niveauer.

Vigtigt: værdier af secrets kan ikke eksporteres fra GitHub. GitHubs API returnerer navnene på secrets, men aldrig værdierne. Enten kender du værdien (roter ved migreringen, anbefales), eller også henter du den fra din autoritative kilde til secrets (password manager, vault, værktøjer til CI-orkestrering).

Indtast secrets igen

For hver secret skal du afgøre:

• Er det en langlivet legitimation, som alligevel burde erstattes af OIDC-føderation? Hvis ja, så sæt OIDC-føderation op til T Cloud Public (se trin 3), og slet secret’en i stedet for at migrere den.
• Er det en API-nøgle til en tredjepart eller en tjenestelegitimation uden et OIDC-alternativ? Roter legitimationen ved kilden, og sæt den nye værdi i fremforge.
• Er det en kryptografisk nøgle, der bruges i builds? Roter den, og sæt den så i fremforge.

Sæt secrets på det rette niveau i fremforges administration:

• Organisations-secrets, tilgængelige for alle repositories i organisationen. Sættes under Administration → Secrets (frem.sh/<org>/_admin/secrets).
• Miljø-secrets, kun tilgængelige i det navngivne miljø (f.eks. production, staging). Sættes under Administration → Miljøer → <env> → Miljøsecrets.
• Repository-secrets, begrænset til ét repository. Sættes under Repository → Indstillinger → Handlinger → Hemmeligheder.

Miljøvariabler (konfiguration, der ikke er hemmelig)

GitHub Actions understøtter env: og vars: på workflow-, job- og step-niveau. fremforge Actions understøtter samme syntaks; inline-variabler kræver ingen migrering.

For variabler på organisations- og repository-niveau (konteksten vars: på GitHub) har fremforge samme opdeling. Sættes under Indstillinger → Handlinger → Variabler i organisationens eller repositoriets Forgejo-indstillinger.

Trin 3: Tilpasning af Actions-workflows

Forgejo Actions er bredt kompatibelt med GitHub Actions, men ikke bit for bit identisk. Et workflow, der kører på GitHub, kører som regel på fremforge med to eller tre konkrete justeringer. Kompatibilitetsmatrixen for de 20 mest brugte Marketplace-actions på docs.frem.sh/marketplace-compat viser, hvilke actions der virker som de er, hvilke der kræver en wrapper, og hvilke der ikke har en modsvarighed på fremforge.

Ændringer, der gælder for næsten alle workflows

1. Uses-referencer kan blive ved med at være actions/*@version for de store GitHub-actions.

fremforges runner slår uses:-direktiver op gennem fremverks spejle kun i EU på https://frem.sh/<owner>/<repo> (én spejlorganisation pr. upstream-udgiver, så actions/checkout peger på frem.sh/actions/checkout); runner-VM’er laver ingen direkte forbindelse ud til github.com, når et job starter (DPA bilag A.6). Det 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 af de officielle actions/*, der allerede er spejlet. Dine uses:-linjer skal ikke ændres for spejlede actions; hvis en reference mangler, så se Almindelige faldgruber nedenfor.

2. ${{ secrets.GITHUB_TOKEN }} opfører sig en smule anderledes.

GitHub leverer et automatisk token med hvert workflow med afgrænsede rettigheder til det kaldende repository. Forgejo leverer det tilsvarende som ${{ secrets.FORGEJO_TOKEN }}, og ${{ secrets.GITHUB_TOKEN }} er et alias for samme token, så de fleste workflows bare virker. Brug et af de to navne frem for det ældre ${{ secrets.GITEA_TOKEN }}. Siden 21. oktober 2026 sætter de hostede runnere (forgejo-runner 13) ikke længere nogen GITEA_*-miljøvariabel, så erstat GITEA_ACTIONS med FORGEJO_ACTIONS eller GITHUB_ACTIONS, og GITEA_ACTIONS_RUNNER_VERSION med FORGEJO_ACTIONS_RUNNER_VERSION. Hvis et workflow forventer bestemt GitHub API-adfærd bag tokenet (f.eks. at det udløser GitHubs Checks API), skal det tilpasses. For Forgejos egne check runs ligger det tilsvarende API på frem.sh/api/v1/repos/{owner}/{repo}/check-runs.

3. Actions, der kalder GitHubs REST API direkte, skal tilpasses.

Hvis et workflow bruger curl https://api.github.com/... eller octokit til at kalde GitHubs REST API direkte, skal de kald i stedet gå til https://frem.sh/_app/api/v1/... med fremforges API (stort set GitHub-kompatibelt på REST-overfladen). Se OpenAPI-spec’en.

4. Standardshell for steps er anderledes.

Forgejo-runnerens standardshell er bash med POSIX-flag. GitHubs runner-standarder er en smule forskellige mellem Linux og Windows/macOS. Hvis dit workflow afhænger af bestemt citat-adfærd i shellen, så sæt eksplicit shell: bash (Linux), shell: pwsh (Windows) eller shell: sh (kun POSIX).

Ændringer, der gælder for nogle workflows

Konteksten if: github.*.

Forgejo Actions stiller github.*-kontekstvariabler til rådighed med de samme navne som i GitHub Actions. Næsten alle if-udtryk kan flyttes uændret. Undtagelserne drejer sig om GitHub-specifikke metadata (f.eks. github.event.pull_request.auto_merge), hvor Forgejo ikke nødvendigvis udstiller præcis samme egenskab.

Marketplace-actions, der er specifikke for GitHubs API.

Eksempler: peter-evans/create-pull-request, marocchino/sticky-pull-request-comment, nwtgck/actions-netlify. De fleste virker uden videre, fordi fremforges REST-overflade accepterer deres API-kald. Nogle få kræver mindre rettelser. Matrixen over de 20 mest brugte beskriver de konkrete løsninger.

Workflows, der skal skrives om

Hvis dit workflow bruger funktioner, der er specifikke for GitHub Enterprise (API’et til organisations-rulesets, GHES-specifikke metrik-endpoints, API’et til Copilot Extensions, GitHub Packages ud over npm/Docker/Maven), skal de funktioner erstattes. Som regel er erstatningen indbygget i fremforge:

• Organisations-rulesets → fremforges politik på organisationsniveau (Administration → Sikkerhed → Politikker → Repository-regler).
• GitHub Packages → fremforges pakke-registry (understøtter npm, Maven, Docker, NuGet, PyPI, RubyGems, Composer, Go).
• Copilot Extensions → bevidst uden for fremforges scope (se indlægget om vores holdning til AI på www.frem.sh).

Trin 4: Ny registrering af SSH-nøgler

Offentlige SSH-nøgler hører til den enkelte bruger og migreres ikke. Hver udvikler tilføjer sin offentlige SSH-nøgle til sin fremforge-konto:

1. Log ind på fremforge.
2. Indstillinger → SSH / GPG nøgler → Tilføj nøgle.
3. Indsæt den offentlige nøgle (~/.ssh/id_ed25519.pub eller tilsvarende).

Fingeraftrykkene for værtsnøglerne til frem.sh er offentliggjort på www.frem.sh/ssh-fingerprints. Udviklere bør kontrollere dem ved første SSH-forbindelse for at undgå et ubemærket MITM-angreb. Fingeraftrykket vises ved første forbindelse; udvikleren sammenligner med siden, bekræfter, og nøglen fastlåses for efterfølgende forbindelser.

For teams, der bruger SSH-certifikatautoriteter, understøtter fremforge konfiguration af betroede CA’er direkte fra organisationens administration på <your-org>/_admin/auth-policy: afsnittet om SSH CA ligger under indstillingen “Tillad SSH-protokol” (lagt ind under Godkendelsespolitik 2026-05-26; den tidligere selvstændige /admin/ssh-ca/ viderestiller hertil). Indsæt din CA’s offentlige OpenSSH-nøgle, vælg en principal-politik (brugernavn / e-mail / opaque), og håndhæv eventuelt “require cert auth”, så almindelig login med offentlig nøgle afvises. Se afsnittet om SSH-certifikatautoritet i vejledningen om godkendelsespolitik for hele opsætningen, herunder eksempler på integration med Smallstep og Vault. Alle brugere, der godkender sig med et certifikat udstedt af CA’en, får adgang med rettighederne fra den matchende fremforge-konto.

For teams, hvor SSO er påkrævet (sso_required = true på organisationsniveau), validerer SSH-godkendelse desuden et OIDC-refresh-token mod tenantens IdP ved hver forbindelse (cachet i 15 minutter). Det betyder, at når en bruger fjernes i IdP’en, er SSH-adgangen spærret inden for 15 minutter, selvom brugerens SSH-nøgle stadig er registreret på fremforge. Der er ikke brug for en separat oprydning af nøgler.

Trin 5: Genforbind tredjepartsintegrationer

Integrationer, der er sat op på GitHub (webhooks, CI-notifikationer til Slack/Teams, deploy-hooks til Vercel/Netlify, synkronisering med issue-trackere som Jira/Linear, kodereviewværktøjer som Sourcegraph eller Graphite), migreres ikke automatisk. Hver enkelt skal forbindes igen.

Webhooks

GitHub-webhooks ligger under Repository → Settings → Webhooks. fremforge-webhooks ligger samme sted i administrationen. Webhook-payloadens form er stort set kompatibel; de vigtigste forskelle:

• Headeren X-GitHub-Event på GitHub hedder X-Forgejo-Event (eller X-Gitea-Event for modtagere, der er kompatible med Gitea) på fremforge. De fleste generiske webhook-modtagere accepterer begge.
• Leverings-id’et er X-Gitea-Delivery + X-Hook-UUID (svarer til GitHubs X-GitHub-Delivery). Begge er med i alle webhook-leveringer fra fremforge, og de fleste modtagere bruger den ene eller den anden som nøgle.
• Hændelsestyperne er et tæt supersæt af GitHubs kernehændelser. push, pull_request, pull_request_review, issues, issue_comment, release, create, delete, fork og star er alle med.
• Signaturheaderen er X-Forgejo-Signature (HMAC-SHA256 med din webhook-secret).

For modtagere, der er skrevet mod GitHubs API (integrationer til Slack, Discord, PagerDuty), er der to muligheder:

1. Konfigurer modtageren til at bruge sin indbyggede Forgejo-integration. Slacks Forgejo-integration, Discords Forgejo-webhookmål osv. findes som regel og er den pæneste vej.
2. Tilpas webhooken på modtagersiden. Hvis modtageren er en intern tjeneste, du selv har lavet, så tilføj håndtering af Forgejo-hændelser ved siden af håndteringen af GitHub-hændelser. Som regel en lille ændring.

CI-integrationer (CircleCI, TravisCI, Jenkins)

Hvis du kører CI uden for forgen (CircleCI, ekstern Jenkins, Buildkite), er migreringen ligetil: peg de CI-systemer på fremforge-repositories i stedet for GitHub-repositories. De fleste eksterne CI-systemer understøtter Forgejo/Gitea som kilde; ændringen af konfigurationen sker i CI-systemet, ikke i fremforge.

De fleste teams, der migrerer til fremforge, bruger lejligheden til at samle alt på fremforges hostede runnere og udfase den eksterne CI. Runner-minutter er inkluderet i den faste pris pr. bruger. Se TCO-indlægget på fremverks blog for regnestykket.

Deploy-mål (Vercel, Netlify, Cloudflare Pages)

Hver tjeneste forbindes til fremforge igen, enten via indbygget understøttelse (Vercel og Netlify har integrationer med Forgejo/Gitea som Git-kilde) eller via en generisk deploy-hook ved Git-push. Notér dine nye webhook-URL’er, og opdater dem i hver tjenestes dashboard.

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

Hvis synkroniseringen med din issue-tracker bygger på Git-commits (der kobler commits til sager via id), bliver den ved med at virke. Commit-SHA’erne bevares gennem migreringen. Hvis synkroniseringen bygger på GitHubs API (lytter efter PR-hændelser, slår GitHub-issues op), så konfigurer den om til fremforge-webhooks, eller slå den fra.

Trin 6: DNS og egne domæner (hvis relevant)

fremforge udleverer kun repository-indhold på frem.sh/<org>/<repo>. Kundeejede Git-domæner understøttes ikke: der er ingen modsvarighed til GitHub Enterprise Servers funktion “custom hostname”, hvor TLS termineres med dit certifikat på git.company.com. To konsekvenser, det er værd at være tydelig om:

Vanity-CNAME uden TLS

En vanity-CNAME i kundens DNS (f.eks. en intern git.company.com CNAME → frem.sh) er teknisk mulig, men det udleverede TLS-certifikat er altid fremforges *.frem.sh-certifikat, IKKE et *.company.com-certifikat. En browser, der går til https://git.company.com/..., viser en advarsel om navneforskel, medmindre kunden også selv udsteder og udleverer sit eget certifikat via sin egen reverse proxy foran. Det er en opgave på kundens side: fremforge terminerer ikke TLS for vanity-hostnavne, accepterer ikke certifikater leveret af kunden og kører ikke et lag med flere certifikater via SNI.

Anbefalet vej for kunder, der migrerer væk fra GitHub Enterprise Server: brug URL-mønstret frem.sh/<org>/* direkte. Opdater interne links, CI-konfigurationer og dokumentation til de nye URL’er. Vejen med vanity-CNAME og kundens eget certifikat giver driftsgæld (fornyelse af certifikater, drift af proxy) og er ikke en konfiguration, fremforge understøtter.

Tag en Enterprise-on-Demand-kontrakt med, hvis dit indkøb kræver en SLA på et vanity-domæne; det åbner for en drøftelse af et dedikeret edge-lag med terminering af kundens certifikat, men det ligger uden for selvbetjeningsniveauet.

Hvad der migreres, og hvad der ikke gør

Dette afsnit opregner, hvilke GitHub-artefakter der kommer gennem migreringen, og med hvilken nøjagtighed. Brug det som tjekliste til forventningsafstemning før migreringen.

Genoptagelse

Forgejos /repos/migrate-endpoint kan ikke genoptages. Hvis kaldet fejler undervejs (netværksudfald, rate limit i kilde-API’et osv.), efterlades det delvist importerede repository i en inkonsistent tilstand. Sådan kommer du videre:

1. Slet det delvise repo i fremforges administration under Indstillinger → Slet.
2. Send migrate-kaldet igen med det samme. Hvis det returnerer 422 med repository already exists, så vent 5 sekunder og prøv igen: det er replikeringsforsinkelse i RDS på læsereplikaen, ikke en tombstone-cyklus i Forgejo.
3. Hvis andet forsøg fejler på samme måde, så brug et nyt repo-navn.

For repos, hvor det er dyrt at køre importen igen (meget LFS, mange issues), så brug udvejen med lokal spejling, der er beskrevet under “Store repositories”; git push --mirror kan naturligt genoptages, fordi Git selv håndterer netværksudfald fint.

Verifikation efter migreringen

Ud over listen “verificer og udfas” i trin 7 nedenfor er dette den tjekliste efter migreringen, som kunderne oftest glemmer:

• Sammenlign antal commits. git rev-list --count HEAD i GitHub-klonen og i fremforge-klonen. Tallene skal være præcis ens.
• Sammenlign listen over branches. git branch -r | sort på hver side, og kør diff på outputtet. Gamle refs/pull/*-refs fra GitHub migreres ikke (Forgejo nummererer PR’er i sit eget ref-rum); alt andet skal stemme.
• Sammenlign listen over tags. git tag --sort=v:refname på hver side; forvent identiske lister.
• Sammenlign antal LFS-pointere. git lfs ls-files | wc -l; tallene skal være præcis ens. Hvis de ikke er det, så kør git lfs fetch --all && git lfs push --all origin mod fremforge-remoten.
• Antal og nummerering af issues og PR’er. gh issue list --limit 5000 --state all --json number | jq length på GitHub mod fremforges /api/v1/repos/<org>/<repo>/issues?state=all (med sideinddeling). Løkke med sideinddeling 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øn CI. Start et build uden ændringer på main, og bekræft, at Forgejo Actions-kørslen ender i success. Det fanger huller i uses:-spejlene (den mest almindelige CI-fejl efter migrering).

Hvis nogen af disse viser afvigelser, så udfas ikke GitHub-kilden, før afvigelsen er løst.

Trin 7: Verificer og udfas

Efter migreringen:

1. Klon det migrerede repository fra fremforge, kør buildet, og bekræft, at testene går igennem.
2. Åbn en test-PR for at bekræfte, at secret-scanneren i pre-receive, afhængighedsscanneren og verifikationen af signerede commits er aktive som forventet.
3. Tjek visningen Fund i administrationen for at bekræfte, at der ikke er overraskende scanningsresultater i den migrerede historik.
4. Bekræft, at webhooks leveres korrekt, under Indstillinger → Webhooks → Seneste leverancer.
5. Bekræft, at SSO-login virker for alle brugere, der skal have adgang til repositoryet.
6. Opdater dokumentation og interne wikier, så de peger på de nye repository-URL’er.
7. Når det har kørt problemfrit på fremforge i 30 dage, så sæt GitHub-repositories til arkiveret tilstand. Slet dem ikke; behold dem som revisionshistorik.

Tilbagerulning (delvis, planlæg derefter)

Migreringen kan delvist rulles tilbage, ikke fuldt ud. Vær ærlig om, hvad der kan og ikke kan komme med tilbage, før du sender produktionstrafik over.

Det KAN en tilbagerulning genskabe:

1. Git-historik: git push --mirror fra en lokal fremforge-klon tilbage til GitHub-repositoryet genskaber branches, tags og commits.
2. Webhooks + integrationer: slå dem til igen på GitHub-siden; du skal selv ændre webhookenes mål-URL’er tilbage til endpoints hostet hos GitHub.

Det kan en tilbagerulning IKKE genskabe fuldt ud:

3. Issues, PR’er og kommentarer, der er oprettet efter migreringen: fremforges Administration → Dataeksport laver et JSON-dump, men GitHubs import-API bruger et andet skema, så en genimport kræver manuel mapping. Issuenumrene vil ikke stemme; krydsreferencer i commit-beskeder vil pege ud i ingenting. Korrekt forfatterangivelse kræver, at alle bidragydere igen har en GitHub-konto. Reaktioner, review-tråde og inline-kommentarers tilknytning til linjer overlever typisk ikke turen frem og tilbage.
4. CI-historik + Actions-logs oprettet på fremforge: kan ikke eksporteres i noget tilsvarende format.
5. fremforge-specifikke fund: afvisninger fra secret-scanning, resultater af afhængighedsscanning og attesteringer af signerede commits oprettet på fremforge har ikke en modsvarighed på GitHub, de kan importeres i.

Behandl migreringen som en envejsdør for produktionsbrug. Kør først en pilot med ét ikke-kritisk repository; bekræft, at CI, webhooks og SSO virker; migrer derefter resten i portioner. Udsagnet “kan rulles tilbage inden for 30 dage” gælder kun tilbagerulning af Git-historikken; regn ikke med det til at genskabe hele samarbejdstilstanden.

Almindelige faldgruber

LFS-objekter er ikke synlige efter migreringen.

Importøren i brugerfladen håndterer automatisk LFS for små puljer (<5 GB). For større puljer skal du selv køre git lfs fetch --all på en lokal spejlklon og git lfs push --all origin til fremforge.

Actions-workflows fejler ved første kørsel med “action not found”.

Spejlene på https://frem.sh/<owner>/<repo> (se opslag af Actions ovenfor) dækker de almindelige actions/* og ti andre udgiverorganisationer. En uses:-reference, der fejler, betyder, at actionen ikke er spejlet endnu: opret en sag på support@frem.sh med den manglende reference, så tager spejlgennemløbet den med i næste runde; eller fastlås til en tidligere version, der allerede er cachet.

Review-kommentarer på PR’er importeres som almindelige kommentarer.

Forgejos importør lægger review-kommentarer på PR’er ind som almindelige PR-kommentarer, ikke som review-kommentarer på linjeniveau. Det er en begrænsning i datamodellen på tværs af forges; inline-kommentarer mister deres tilknytning til linjen. Løsning: for repositories, hvor inline-kommentarer er vigtige, så eksporter dem til en separat datafil via GitHubs API før migreringen, og gem dem som en arkiveret vedhæftning på den migrerede PR.

Brugere bliver ikke matchet automatisk.

Importøren matcher GitHub-brugere på e-mailadresse. Brugere, hvis e-mail på GitHub ikke svarer til deres e-mail på fremforge (f.eks. privat e-mail på GitHub og firma-e-mail på fremforge), vises som “Unknown user” på importerede issues. Du kan enten matche på forhånd ved at tilføje e-mailen fra GitHub som sekundær e-mail på fremforge-kontoen før importen, eller acceptere visningen “Unknown user” og lade den oprindelige forfatterangivelse i commit-historikken stå for sig selv.

Få hjælp

Hvis noget i denne vejledning ikke virker i din opsætning:

• Skriv til support@frem.sh med en emnelinje, der starter med MIGRATION, GITHUB -, og en beskrivelse af, hvor du gik i stå.
• Hvis du er på early adopter-planen, har du en direkte linje til fremforges udviklingsteam og får hjælp til migreringen uden ekstra betaling.

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