Migrera till fremforge från GitHub

Den här guiden tar ett typiskt GitHub-team genom en migrering till fremforge. Den täcker GitHub.com, GitHub Enterprise Cloud (GHEC) och GitHub Enterprise Server (GHES). Läs den från början till slut innan du börjar. Överraskningar mitt i en migrering blir dyra.

Inte redo att flytta allt på en gång? Använda fremforge parallellt med GitHub visar hur du speglar repon så att fremforge skannar dem, och hur du laddar upp SBOM:er från GitHub Actions medan flytten pågår.

Om du ännu inte har kört checklistan före migrering mot din nuvarande GitHub-tenant, gör det först. Den lyfter fram stora repon, LFS-användning, beroenden till Marketplace-actions och tredjepartsintegrationer som kräver särskild uppmärksamhet.

Innan du börjar

Vad du behöver på din sida:

• Ett konto med ägarroll i den GitHub-organisation som du migrerar från.
• En personlig åtkomsttoken på GitHub med scopen repo, admin:org, workflow och admin:public_key (klassisk PAT) eller motsvarande finkorniga token.
• Administratörsåtkomst till den fremforge-organisation som du migrerar till (organisationen skapas när du registrerar dig).
• För migrering av Actions: en förteckning över de GitHub Marketplace-actions som du använder i dag och deras versioner.

Vad vi rekommenderar:

• Frys nya PR:er och merges till de huvudbranchar som du migrerar under migreringsfönstret. Samtidiga skrivningar under migreringen ger avstämningsproblem som du inte behöver.
• Kör först migreringen mot en testorganisation på fremforge som inte är produktion, om du är osäker på hur dina arbetsflöden anpassas. Den kostnadsfria provperioden på 30 dagar är utformad för just detta.
• Migrera ett repo hela vägen och kontrollera att det byggs utan fel innan du migrerar resten i bulk.

Tidsuppskattning (planeringsintervall, inte åtaganden):

• Ett enskilt litet repo (≤100 MB, ingen LFS, enkla Actions): 15–30 minuters eget arbete plus verifiering i CI.
• Ett medelstort repo (≤1 GB, viss LFS, måttligt komplexa Actions): 1–2 timmar inklusive anpassning av arbetsflöden.
• En bulkmigrering av 20–50 repon: 1–2 ingenjörsdagar fördelade över en vecka, där anpassningen av Actions tar mest tid snarare än själva migreringen av repona.

Intervallen bygger på en genomgång av dokumentationen mot Forgejos prestandaegenskaper upstream och 2 interna migreringar hos fremverk före lanseringen; verkliga tider kommer att baseras på våra första 5 kundmigreringar. De är planeringshjälp, inte avtalsmässiga SLA:er. Den verkliga migreringstiden växer med: (a) antal repon och total LFS-volym; (b) hur komplexa dina Actions är och hur många uses:-referenser som måste skrivas om mot fremforges runner-spegel; (c) hur stort team som kan bära verifieringsarbetet. Om du migrerar fler än 50 repon eller har en icke-trivial användning av Actions, planera för minst 2× den övre gränsen som marginal och kör först en pilot med ett enda repo.

Jämförelse av funktioner

Vad fremforge levererar i dag jämfört med GitHub Enterprise Cloud, med fokus på de säkerhets- och autentiseringsfunktioner som kunder frågar mest om:

fremforge ger nya organisationer bara Git-åtkomst över HTTPS som standard (SSH är avstängt som standard sedan 2026-05-22) med den förregistrerade OAuth-appen för Git Credential Manager: utvecklare får MFA via organisationens IdP vid varje förnyelse vid push. Tabellen nedan visar var varje funktion hamnar.

Den strategiska skillnaden mot GHEC: fremforge behandlar HTTPS+GCM som den primära vägen eftersom MFA följer med naturligt via IdP:n vid varje förnyelse av token; SSH aktiveras per organisation eftersom IP-tillämpningen är strukturellt svagare i den här stacken. För de flesta krav på säkerhetsnivå i företag (”MFA vid varje push”, ”begränsa med IP varifrån utvecklare får pusha”) är standarden HTTPS+GCM strikt starkare än standarden med SSH-nycklar som GHEC ärver från GitHubs historia.

Steg 1: Migrering av repo och historik

fremforge kör Forgejo från upstream, som har en inbyggd importör för GitHub-repon. Importören kopierar hela Git-historiken, issues, pull requests, kommentarer, etiketter, milstolpar, wikiinnehåll och releaser, inte bara standardbranchen.

Använda den inbyggda importören (via gränssnittet)

Från fremforges administrationsgränssnitt för din organisation:

1. Klicka på + → Ny migrering.
2. Välj GitHub som källa.
3. Klistra in URL:en till GitHub-repot (t.ex. https://github.com/acme/backend).
4. Klistra in din personliga åtkomsttoken från GitHub. Token används bara för den här importen och sparas inte när importen är klar.
5. Markera de innehållstyper som ska importeras: Wiki, Issues, Pull requests, Releases, Labels, Milestones.
6. Välj målorganisation och reponamn på fremforge. Standardvärdena speglar källan på GitHub.
7. Klicka på Migrate repository.

Importören körs i bakgrunden. För ett typiskt repo på 100–500 MB med måttlig historik av issues/PR:er kan du räkna med 2–10 minuter. En förloppsindikator i administrationsgränssnittet visar aktuellt steg (kloning av Git-historik, import av issues, import av PR:er, import av releaser).

Använda API:t (skriptbar väg)

För bulkmigreringar skriptar du importen mot fremforges API. Endpoints för migrering, repon, issues och PR:er är Forgejos inbyggda API-yta som fremforge exponerar oförändrad på frem.sh/_app/api/v1/...; de dokumenteras inte separat i fremforges OpenAPI-specifikation (som bara täcker fremforges tillägg i kontrollplanet: användare, policy, fynd, exporter, mandat). Referensen för Forgejos inbyggda endpoints finns i docs.frem.sh/api/openapi.yaml eller i Forgejos OpenAPI-dokumentation upstream på docs.codeberg.org/api/. fremforge driftar inte Forgejos Swagger UI i produktion (avsiktligt avstängt, eftersom det är ett känt mål för rekognosering). Alla endpoints nedan är standard-API:t i 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 flera repon parallellt med GNU parallel eller ett litet styrskript. Begränsa till 3–5 samtidiga importer så att du varken mättar GitHubs hastighetsgräns för PAT eller din lokala bandbredd.

Vad importören importerar och inte importerar

Importeras korrekt:

• Alla branchar och taggar, med fullständig commit-historik.
• Issues med titlar, brödtext, kommentarer, etiketter, milstolpar och tilldelade personer (mappade via e-postadress där användaren finns på fremforge).
• Pull requests inklusive granskningskommentarer, merge-status och orsak till stängning. Öppna PR:er blir öppna PR:er; stängda PR:er är stängda.
• Releaser inklusive binära bilagor (flyttas till fremforges LFS-lagring i EU).
• Wikisidor.

Importeras inte:

• Körhistorik för GitHub Actions-arbetsflöden. Historiska körningar stannar på GitHub; nya körningar börjar från noll på fremforge.
• Värden för secrets och miljövariabler: dem anger du igen (se steg 2).
• Tredjepartsintegrationer som är konfigurerade på GitHub. De måste anslutas igen (se steg 5).
• GitHub Projects (klassiska eller Projects v2). Forgejo har ingen exakt motsvarighet; grundläggande innehåll i projekttavlor kan återskapas manuellt eller via fremforges funktion Projects (fas 1.5).
• Dependabot-larm. fremforges beroendeskanning körs oberoende med Trivy/osv-scanner och tar fram egna fynd.
• Säkerhetsmeddelanden för repon. Återskapa de som du vill behålla under Säkerhet › Rapporter › Säkerhetsmeddelanden (Säkerhetsmeddelanden), eller via dess API utifrån GitHubs GET /repos/{owner}/{repo}/security-advisories; publicerade meddelanden får ett nytt FFSA--id, så behåll GHSA-id:t bland referenserna.
• GitHub Discussions. Ingen motsvarighet i Forgejo i dag.
• Aviseringsinställningar per användare. Medlemmarna prenumererar igen på fremforge.

Stora repon

Om ditt repo är större än 2 GB eller ditt LFS-lager överstiger 5 GB kan importören i gränssnittet få timeout. Forgejos endpoint /repos/migrate har ingen inställning för timeout per anrop, så den rekommenderade reservvägen är att göra en direkt spegelkloning med Git lokalt och köra git push --mirror till ett tomt fremforge-repo som du har skapat i förväg:

# 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 den här vägen följer inte historiken för issues och PR:er med. Importera den separat via Forgejos migrerings-API (POST /api/v1/repos/migrate, se det kanoniska curl-exemplet högst upp på sidan) med "wiki": false, "issues": true, "pull_requests": true, och peka anropet mot URL:en till det redan pushade fremforge-repot så att bara metadata hämtas från GitHub.

Secret-skanningen i pre-receive spärrar den här pushen. fremforge kör gitleaks som en pre-receive-hook i Forgejo vid varje push, även i --mirror-formen ovan. Om dina historiska commits innehåller riktiga secrets (läckta AWS-nycklar, utgångna Stripe-token, inbäddade privata nycklar) avvisas pushen och de matchande commit-SHA:erna skrivs ut, och hela speglingen misslyckas atomärt. Det är avsiktligt: att importera en secret från publik historik till fremforge roterar den INTE i tysthet hos leverantören upstream, så den säkra vägen är att först rensa och sedan importera. Två sätt att gå vidare:

1. Rensa historiken först med git-filter-repo (rekommenderas) eller BFG Repo-Cleaner, och pusha sedan igen. Meddela ägaren till den secret som läckt att historiken hos leverantören upstream också läcker, oavsett vad du gör på målsidan: rotera de läckta autentiseringsuppgifterna vid källan.
2. Begär ett engångsundantag från support@frem.sh för kända återkallade secrets i arkiverad historik. Undantaget loggas, granskas och knyts till en skriftlig bekräftelse på att dessa secrets redan är roterade.

Landa main först så att LFS-pushen blir användbar. Eftersom git push --mirror är atomär mot gitleaks (alla refs i en transaktion; ett avvisande = tom spegel = LFS-pushen har inget att pusha till) lönar det sig att först göra en push av en enda branch för att bekräfta regelflödet innan du pushar alla refs. Mellan git remote set-url och git push --mirror:

git push origin main --force-with-lease

Om main går igenom går resten av refs nästan alltid igenom (gitleaks-reglerna utgår från innehåll, inte branch). Om main avvisas, rensa eller begär undantag innan du försöker spegla igen: det finns inget värde i att pusha andra refs så länge commiten med en secret på main finns kvar.

Hooken är samma regelflöde för gitleaks som skyddar varje fremforge-repo, inte en kontroll som är specifik för migrering. Kör pre-migration-check.sh innan du börjar; det lyfter fram samma fynd som hooken skulle fånga, så att du kan rensa innan migreringsfönstret öppnar.

LFS-lagringskvot och kapacitet för stora repon

git lfs push --all origin skriver objekt till din fremforge-tenants LFS-kvot. Planera kvoterna:

Två praktiska gränser ligger under abonnemangets kvot:

• Storlek på bart git-repo. Om repots bara .git (efter git gc --aggressive) överstiger ~5 GiB, kontakta support@frem.sh före migreringen så att vi kan bekräfta att det finns utrymme för ditt repo.
• Mycket stora LFS-pushar. git lfs push av mer än ~100 GiB i en enda session kan behöva delas upp i omgångar om ≤50 GiB för att undvika strypning av hastighetsgränsen. Felet visar sig som HTTP 503 med X-Reserved: ratelimit i svaret: vänta 60 s och fortsätt; LFS går att återuppta.

Om du är osäker på hur stort LFS-lagret blir, kör git lfs ls-files --size --all | awk '{s+=$2} END {print s/1024/1024/1024 " GiB"}' mot källrepot innan du startar spegelpushen.

Steg 2: Secrets och miljövariabler

GitHub lagrar secrets på organisations-, miljö- och reponivå. fremforge använder samma tre nivåer.

Viktigt: värden för secrets kan inte exporteras från GitHub. GitHubs API returnerar namnen på secrets men aldrig värdena. Antingen känner du till värdet (rotera vid migreringen, rekommenderas) eller så hämtar du det från den källa som är sanningen för din hantering av secrets (lösenordshanterare, valv, verktyg för CI-orkestrering).

Ange secrets igen

Bestäm för varje secret:

• Är det en långlivad autentiseringsuppgift som ändå borde ersättas med OIDC-federation? Om ja, konfigurera OIDC-federation mot T Cloud Public (se steg 3) och ta bort secreten i stället för att migrera den.
• Är det en API-nyckel från tredje part eller en tjänsteuppgift utan OIDC-alternativ? Rotera uppgiften vid källan och ange sedan det nya värdet i fremforge.
• Är det en kryptografisk nyckel som används i byggen? Rotera den och ange den sedan i fremforge.

Ange secrets på rätt nivå i fremforges administrationsgränssnitt:

• Organisationens secrets, tillgängliga för varje repo i organisationen. Anges under Organisationens administration → Secrets (frem.sh/<org>/_admin/secrets).
• Miljöns secrets, tillgängliga bara i den namngivna miljön (t.ex. production, staging). Anges under Organisationens administration → Miljöer → <env> → Miljösecrets.
• Repositoryts secrets, avgränsade till ett repo. Anges under Repot → Inställningar → Actions → Hemligheter.

Miljövariabler (konfiguration som inte är hemlig)

GitHub Actions stöder env: och vars: på arbetsflödes-, jobb- och stegnivå. fremforge Actions stöder samma syntax; ingen migrering behövs för variabler som anges direkt i arbetsflödet.

För variabler på organisations- och reponivå (kontexten vars: i GitHub) har fremforge samma avgränsning. Anges under Inställningar → Actions → Variabler i organisationens eller repots Forgejo-inställningar.

Steg 3: Anpassning av Actions-arbetsflöden

Forgejo Actions är i stort sett kompatibelt med GitHub Actions men inte identiskt bit för bit. Ett arbetsflöde som körs på GitHub körs oftast på fremforge efter två eller tre specifika justeringar. Kompatibilitetsmatrisen för de 20 vanligaste Marketplace-actions på docs.frem.sh/marketplace-compat dokumenterar vilka actions som fungerar som de är, vilka som behöver ett omslag och vilka som saknar motsvarighet i fremforge.

Ändringar som gäller nästan alla arbetsflöden

1. Uses-referenser kan stå kvar som actions/*@version för de stora GitHub-actions.

fremforges runner löser upp uses:-direktiv via fremverks speglar enbart i EU på https://frem.sh/<owner>/<repo> (en spegelorganisation per publicist upstream, så actions/checkout löses upp till frem.sh/actions/checkout); runner-VM:er gör ingen direkt utgående trafik till github.com när ett jobb startar (DPA bilaga A.6). Det fungerar för actions/checkout, actions/setup-node, actions/setup-go, actions/setup-python, actions/setup-java, actions/cache, actions/upload-artifact, actions/download-artifact och resten av de officiella actions/* som redan är speglade. Du behöver inte ändra dina uses:-rader för speglade actions; om en referens saknas, se Vanliga fallgropar nedan.

2. Semantiken för ${{ secrets.GITHUB_TOKEN }} skiljer sig något.

GitHub levererar en automatisk token med varje arbetsflöde, med avgränsade behörigheter till det anropande repot. Forgejo levererar en motsvarighet som ${{ secrets.FORGEJO_TOKEN }}, och ${{ secrets.GITHUB_TOKEN }} är ett alias för samma token, så de flesta arbetsflöden fungerar direkt. Använd ett av de två namnen i stället för det äldre ${{ secrets.GITEA_TOKEN }}. Sedan den 21 oktober 2026 sätter de driftade runnerna (forgejo-runner 13) inte längre någon GITEA_*-miljövariabel, så ersätt GITEA_ACTIONS med FORGEJO_ACTIONS eller GITHUB_ACTIONS, och GITEA_ACTIONS_RUNNER_VERSION med FORGEJO_ACTIONS_RUNNER_VERSION. Om ett arbetsflöde förväntar sig specifika beteenden i GitHubs API bakom den token (t.ex. att utlösa GitHubs Checks API) behöver det anpassas. För Forgejos inbyggda check runs finns motsvarande API på frem.sh/api/v1/repos/{owner}/{repo}/check-runs.

3. Actions som anropar GitHubs REST API direkt behöver anpassas.

Om ett arbetsflöde använder curl https://api.github.com/... eller octokit för att anropa GitHubs REST API direkt, måste anropen riktas mot https://frem.sh/_app/api/v1/... med fremforges API (till stor del GitHub-kompatibelt på REST-ytan). Se OpenAPI-specifikationen.

4. Standardskalet för steg skiljer sig.

Forgejo-runnerns standardskal är bash med POSIX-flaggor. GitHubs runner har subtilt olika standardvärden på Linux och Windows/macOS. Om ditt arbetsflöde är beroende av ett visst beteende för citattecken i skalet, ange uttryckligen shell: bash (Linux), shell: pwsh (Windows) eller shell: sh (enbart POSIX).

Ändringar som gäller vissa arbetsflöden

Kontexten if: github.*.

Forgejo Actions tillhandahåller kontextvariablerna github.* med samma namn som GitHub Actions. Nästan alla if-uttryck kan flyttas utan ändring. Undantagen gäller GitHub-specifik metadata (t.ex. github.event.pull_request.auto_merge) där Forgejo kanske inte exponerar exakt samma egenskap.

Marketplace-actions som är specifika för GitHubs API.

Exempel: peter-evans/create-pull-request, marocchino/sticky-pull-request-comment, nwtgck/actions-netlify. De flesta fungerar direkt eftersom fremforges REST-yta accepterar deras API-anrop. Ett fåtal behöver mindre patchar. Topp 20-matrisen dokumenterar specifika lösningar.

Arbetsflöden som måste skrivas om

Om ditt arbetsflöde använder funktioner som är specifika för GitHub Enterprise (API:t för organisationens rulesets, GHES-specifika endpoints för mätvärden, API:t för Copilot extensions, GitHub Packages utöver npm/Docker/Maven) måste de funktionerna ersättas. Oftast är ersättningen inbyggd i fremforge:

• Organisationens rulesets → policy på organisationsnivå i fremforge (Organisationens administration → Säkerhet → Policyer → Repo-regler).
• GitHub Packages → fremforges paketregister (stöder npm, Maven, Docker, NuGet, PyPI, RubyGems, Composer, Go).
• Copilot Extensions → utanför fremforges omfattning med avsikt (se inlägget om vår AI-hållning på www.frem.sh).

Steg 4: Ny registrering av SSH-nycklar

Publika SSH-nycklar hör till varje användare och migreras inte. Varje utvecklare lägger till sin publika SSH-nyckel i sitt fremforge-konto:

1. Logga in på fremforge.
2. Inställningar → SSH/GPG-nycklar → Lägg till nyckel.
3. Klistra in den publika nyckeln (~/.ssh/id_ed25519.pub eller motsvarande).

Fingeravtrycken för värdnycklarna till frem.sh publiceras på www.frem.sh/ssh-fingerprints. Utvecklare bör kontrollera dem vid den första SSH-anslutningen för att förhindra en obemärkt MITM-attack. Fingeravtrycket visas vid första anslutningen; utvecklarna jämför med förtroendesidan, bekräftar, och nyckeln fästs för senare anslutningar.

För team som använder SSH-certifikatutfärdare stöder fremforge konfiguration av betrodda CA:er direkt i organisationens administrationsgränssnitt på <your-org>/_admin/auth-policy: avsnittet om SSH-CA ligger under reglaget ”Tillåt SSH-protokollet” (inbakat i Autentiseringspolicy 2026-05-26; den fristående /admin/ssh-ca/ omdirigerar hit). Klistra in din CA:s publika OpenSSH-nyckel, välj en principal-policy (användarnamn / e-post / opak) och kräv valfritt ”kräv certifikatautentisering” så att vanlig inloggning med publik nyckel nekas. Se avsnittet om SSH-certifikatutfärdare i guiden för autentiseringspolicy för hela konfigurationen, inklusive exempel på integration med Smallstep och Vault. Varje användare som autentiserar sig med ett certifikat som CA:n har utfärdat släpps in med behörigheterna för det matchande fremforge-kontot.

För team där SSO är obligatoriskt (sso_required = true på organisationsnivå) validerar SSH-autentiseringen dessutom en OIDC-uppdateringstoken mot tenantens IdP vid varje anslutning (cachas i 15 minuter). Det innebär att en användare som avprovisioneras i IdP:n blockeras från SSH-åtkomst inom 15 minuter, även om SSH-nyckeln fortfarande är registrerad på fremforge. Ingen separat rensning av nycklar behövs.

Steg 5: Återanslutning av tredjepartsintegrationer

Integrationer som är konfigurerade på GitHub (webhooks, CI-aviseringar till Slack/Teams, deploy-hooks till Vercel/Netlify, synkning av ärendehantering med Jira/Linear, verktyg för kodgranskning som Sourcegraph eller Graphite) migreras inte automatiskt. Var och en måste anslutas igen.

Webhooks

GitHubs webhooks finns under Repository → Settings → Webhooks. fremforges webhooks finns på samma ställe i administrationsgränssnittet. Formatet på webhook-payloads är till stor del kompatibelt; de viktigaste skillnaderna:

• Huvudet X-GitHub-Event på GitHub heter X-Forgejo-Event (eller X-Gitea-Event för mottagare som är kompatibla med Gitea) på fremforge. De flesta generiska webhook-mottagare accepterar båda.
• Leveransidentifieraren är X-Gitea-Delivery + X-Hook-UUID (motsvarigheten till GitHubs X-GitHub-Delivery). Båda finns med i varje webhook-anrop från fremforge, och de flesta mottagare använder någon av dem som nyckel.
• Händelsetyperna är en nära övermängd av GitHubs kärnhändelser. push, pull_request, pull_request_review, issues, issue_comment, release, create, delete, fork och star finns alla.
• Signaturhuvudet är X-Forgejo-Signature (HMAC-SHA256 med din webhook-secret).

För mottagare som är skrivna mot GitHubs API (integrationer för Slack, Discord, PagerDuty) finns två alternativ:

1. Konfigurera om mottagaren så att den använder sin inbyggda Forgejo-integration. Slacks Forgejo-integration, Discords webhook-mål för Forgejo och liknande finns oftast och är den renare vägen.
2. Anpassa webhooken på mottagarsidan. Om mottagaren är en egen intern tjänst, lägg till hantering av Forgejo-händelser vid sidan av hanteringen av GitHub-händelser. Oftast en liten ändring.

CI-integrationer (CircleCI, TravisCI, Jenkins)

Om du kör CI utanför forgen (CircleCI, extern Jenkins, Buildkite) är migreringen enkel: peka de CI-systemen mot fremforge-repon i stället för GitHub-repon. De flesta externa CI-system stöder Forgejo/Gitea som källa; konfigurationsändringen görs i CI-systemet, inte i fremforge.

De flesta team som migrerar till fremforge passar på att samla allt på fremforges driftade runners och avveckla den externa CI:n. Runner-minuter ingår i det fasta priset per användare. Se TCO-inlägget på fremverks blogg för beräkningen.

Driftsättningsmål (Vercel, Netlify, Cloudflare Pages)

Varje tjänst ansluts till fremforge igen, antingen via inbyggt stöd (Vercel och Netlify har Git-källintegrationer för Forgejo/Gitea) eller via en generisk deploy-hook som utlöses av Git-push. Dokumentera dina nya webhook-URL:er och uppdatera dem i respektive tjänsts dashboard.

Synkning av ärendehantering (Jira, Linear, Zendesk)

Om din synkning av ärendehanteringen bygger på Git-commits (kopplar commits till ärenden via id) fortsätter den att fungera. Commit-SHA:erna bevaras genom migreringen. Om synkningen bygger på GitHubs API (lyssnar på PR-händelser, frågar efter GitHub-issues), konfigurera om den så att den använder fremforges webhooks, eller stäng av den.

Steg 6: DNS och egna domäner (om tillämpligt)

fremforge levererar repoinnehåll enbart på frem.sh/<org>/<repo>. Egna Git-domäner som ägs av kunden stöds inte: det finns ingen motsvarighet till GitHub Enterprise Servers funktion ”custom hostname” där TLS termineras med ditt certifikat på git.company.com. Två konsekvenser som är värda att vara tydlig med:

Vanity-CNAME utan TLS

En vanity-CNAME i kundens DNS (t.ex. en intern git.company.com CNAME → frem.sh) är tekniskt möjlig, men TLS-certifikatet som levereras är alltid fremforges *.frem.sh-certifikat, INTE ett *.company.com-certifikat. En webbläsare som går till https://git.company.com/... visar en varning om namnmatchning, om inte kunden också tar fram och levererar ett eget certifikat via en egen omvänd proxy framför. Det är ett åtagande på kundens sida: fremforge terminerar inte TLS för vanity-värdnamn, accepterar inte certifikat från kunder och kör inget SNI-lager med flera certifikat.

Rekommenderad väg för kunder som migrerar från GitHub Enterprise Server: använd URL-mönstret frem.sh/<org>/* direkt. Uppdatera interna länkar, CI-konfigurationer och dokumentation till de nya URL:erna. Vägen med vanity-CNAME och kundens eget certifikat ger driftskuld (förnyelse av certifikat, drift av proxy) och är inte en konfiguration som fremforge stöder.

Ta med ett Enterprise-on-Demand-avtal om din upphandling kräver en SLA för vanity-domäner: det öppnar för en diskussion om en dedikerad edge-nivå med terminering av kundens certifikat, men det ligger utanför självbetjäningsnivån.

Vad som migreras och inte migreras

Det här avsnittet räknar upp vilka artefakter från GitHub som följer med i migreringen och med vilken trohet. Använd det som checklista för att stämma av före migreringen.

Återupptagning

Forgejos endpoint /repos/migrate går inte att återuppta. Om anropet misslyckas halvvägs (nätverksavbrott, hastighetsgräns i källans API osv.) lämnas det delvis importerade repot i ett inkonsekvent tillstånd. Så återhämtar du dig:

1. Ta bort det delvis importerade repot via Inställningar → Radera i fremforges administrationsgränssnitt.
2. Gör migreringsanropet igen direkt. Om det returnerar 422 med repository already exists, vänta 5 sekunder och försök igen: det är replikeringsfördröjning i RDS på läsrepliken, inte en cykel med gravstenar i Forgejo.
3. Om även det andra försöket misslyckas på samma sätt, använd ett nytt reponamn.

För repon där det är dyrt att köra importen igen (stor LFS, många issues), använd reservvägen med lokal spegel som beskrivs under ”Stora repon”: git push --mirror går naturligt att återuppta eftersom git själv hanterar nätverksavbrott smidigt.

Verifiering efter migreringen

Utöver listan ”verifiera och avveckla” i steg 7 nedan är det här de punkter i verifieringen efter migreringen som kunder oftast glömmer:

• Jämför antal commits. git rev-list --count HEAD i klonen från GitHub jämfört med klonen från fremforge. Talen måste stämma exakt.
• Jämför branchlistan. git branch -r | sort på båda sidor och diff på utdata. Inaktuella refs/pull/*-refs från GitHub migreras inte (Forgejo numrerar PR:er i sin egen ref-rymd); allt annat ska stämma.
• Jämför tagglistan. git tag --sort=v:refname på båda sidor; listorna ska vara identiska.
• Jämför antal LFS-pekare. git lfs ls-files | wc -l; talen ska stämma exakt. Om de inte gör det, kör git lfs fetch --all && git lfs push --all origin mot fremforge-remoten.
• Antal issues/PR:er + numrering. gh issue list --limit 5000 --state all --json number | jq length på GitHub jämfört med fremforges /api/v1/repos/<org>/<repo>/issues?state=all (med sidindelning). Sidindelningsloop för 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. Numreringen bevaras.
• Grön CI. Utlös ett bygge utan ändringar på main och kontrollera att körningen i Forgejo Actions når success. Det fångar luckor i uses:-speglarna (det vanligaste CI-felet efter en migrering).

Om någon av punkterna visar avvikelser, avveckla inte källan på GitHub förrän avvikelsen är åtgärdad.

Steg 7: Verifiera och avveckla

Efter migreringen:

1. Klona det migrerade repot från fremforge, kör bygget och kontrollera att testerna går igenom.
2. Öppna en test-PR för att kontrollera att secret-skannern i pre-receive, beroendeskannern och verifieringen av signerade commits är aktiva som väntat.
3. Titta i vyn Fynd i administrationsgränssnittet för att bekräfta att skanningen av den migrerade historiken inte gav några överraskande resultat.
4. Kontrollera att webhooks levereras korrekt via Inställningar → Webbkrokar → Färska leveranser.
5. Kontrollera att SSO-inloggningen fungerar för varje användare som ska komma åt repot.
6. Uppdatera dokumentation och interna wikis så att de pekar på de nya repo-URL:erna.
7. Efter 30 dagars problemfri drift på fremforge, arkivera GitHub-repona. Ta inte bort dem; behåll dem för granskningshistoriken.

Återställning (delvis, planera därefter)

Migreringen går delvis att återställa, inte helt. Var ärlig om vad som klarar en tur och retur och vad som inte gör det innan du flyttar produktionstrafik.

Vad en återställning KAN återskapa:

1. Git-historik: git push --mirror från en lokal fremforge-klon tillbaka till GitHub-repot återställer branchar, taggar och commits.
2. Webhooks + integrationer: slå på dem igen på GitHub-sidan; du behöver manuellt ändra webhook-målens URL:er tillbaka till endpoints hos GitHub.

Vad en återställning INTE kan återskapa med full trohet:

3. Issues, PR:er och kommentarer som skapats efter migreringen: fremforges Organisationens administration → Dataexport ger en JSON-dump, men GitHubs import-API använder ett annat schema, så återimport blir ett manuellt mappningsarbete. Issue-numren kommer inte att stämma; korsreferenser i commit-meddelanden pekar i tomma intet. Upphovsattribuering kräver att varje bidragsgivare har ett GitHub-konto igen. Reaktioner, granskningstrådar och inline-kommentarernas radfästning överlever vanligtvis inte turen och returen.
4. CI-historik + Actions-loggar som skapats på fremforge: kan inte exporteras i något motsvarande format.
5. fremforge-specifika fynd: avvisningar från secret-skanningen, resultat från beroendeskanningen och attesteringar av signerade commits som skapats på fremforge har ingen motsvarighet på GitHub att importera till.

Behandla migreringen som en enkelriktad dörr för produktionsanvändning. Kör först en pilot med ett enda repo som inte är kritiskt; kontrollera att CI, webhooks och SSO fungerar; migrera sedan resten i omgångar. Formuleringen ”reversibel inom 30 dagar” gäller bara återställning av Git-historiken; lita inte på den för att återskapa hela samarbetstillståndet.

Vanliga fallgropar

LFS-objekt syns inte efter migreringen.

Importören i gränssnittet hanterar LFS automatiskt för små lager (<5 GB). För större lager kör du git lfs fetch --all på en lokal spegelklon och git lfs push --all origin till fremforge manuellt.

Actions-arbetsflöden misslyckas vid första körningen med ”action not found”.

Speglarna på https://frem.sh/<owner>/<repo> (se upplösning av Actions ovan) täcker standarduppsättningen actions/* och tio andra publicistorganisationer. En misslyckad uses:-referens betyder att actionen inte har speglats än: öppna ett ärende via support@frem.sh med den saknade referensen, så plockar spegelsvepet upp den i nästa cykel; eller fäst en tidigare upplöst version som redan finns i cachen.

Granskningskommentarer i PR importeras som vanliga PR-kommentarer.

Forgejos importör mappar granskningskommentarer i PR:er till PR-kommentarer, inte till granskningskommentarer på radnivå. Det är en begränsning i datamodellen mellan forgar; inline-granskningskommentarer förlorar sin koppling till raden. Lösning: för repon där inline-kommentarer är viktiga, exportera dem till en separat datafil via GitHubs API före migreringen och bevara dem som en arkivbilaga på den migrerade PR:en.

Användare mappas inte automatiskt.

Importören mappar GitHub-användare via e-postadress. Användare vars e-post på GitHub inte stämmer med e-posten på fremforge (t.ex. privat e-post på GitHub, företagets e-post på fremforge) visas som ”Unknown user” på importerade issues. Antingen mappar du i förväg genom att lägga till e-postadressen från GitHub som sekundär e-postadress på fremforge-kontot före importen, eller så accepterar du visningen ”Unknown user” och förlitar dig på den ursprungliga attribueringen som syns i commit-historiken.

Få hjälp

Om något i den här guiden inte fungerar för din konfiguration:

• Mejla support@frem.sh med en ämnesrad som börjar med MIGRATION, GITHUB - och en beskrivning av var du kört fast.
• Om du har early adopter-abonnemanget har du en direktlinje till fremforges utvecklingsteam för hjälp med migreringen utan extra kostnad.

Se även: Migreringsguide för GitLab · Migreringsguide för Azure DevOps · Kompatibilitetsmatris för de 20 vanligaste Marketplace-actions · Checklista före migrering.