Migrationsguide · Från GitHub
Migrera från GitHub till SIAX Git och CI
GitHub är inte ett dåligt verktyg, och det är sällan skälet till att någon flyttar. Skälen är oftast tre: licenskostnaden per utvecklare som växer med teamet, CI-minuter som är svåra att förutsäga, och att både koden och byggkedjan ligger under amerikansk jurisdiktion. För bolag som säljer till offentlig sektor eller reglerade kunder är det sista argumentet ofta det som avgör.
Vår Git och CI är självhostad Gitea med Actions-kompatibla runners, allt i EU. Git-protokollet är detsamma, så kloner, remotes och verktyg fungerar oförändrat, och workflow-syntaxen är i huvudsak densamma som GitHub Actions. Priset är 199 kr/mån för tio användare, mot licens per utvecklare plus rörlig CI-kostnad.
Den ärliga varningen: Actions-kompatibiliteten är god men inte identisk. Workflow-filerna kan oftast kopieras rakt av, men enskilda marketplace-actions behöver bytas ut, och delar av GitHubs ekosystem — Codespaces, Advanced Security, Pages, OIDC-federation mot molnleverantörer — har ingen motsvarighet. Den här guiden lägger tiden där arbetet faktiskt finns: i pipelinen, inte i koden.
Tidsåtgång
En halvdag för ett repo med en enkel pipeline. För 20-30 repon med aktiva workflows: räkna med två till tre arbetsdagar, där merparten går åt till att testa om workflows — inte till att flytta kod.
Stillestånd
Ingen för koden. Git är distribuerat och alla har fullständiga kloner, så själva repoflytten märks inte. CI har däremot ett glapp: under omskrivningen finns en period där bygget bara är verifierat på ett av systemen. Kör båda parallellt tills utfallen matchar innan ni gör vår CI obligatorisk.
Så gör du
- 1
Inventera repon, workflows och integrationer
Lista alla repon med senaste commit, storlek och om de använder LFS. Gå igenom varje aktivt workflow och notera vilka actions det använder, vilka hemligheter det läser och vad det deployar till. Notera också allt som ligger utanför Git: GitHub Apps, webhooks, branch-skydd, kodägare och obligatoriska statuskontroller. Den listan är er faktiska kravspec — inte repolistan.
- 2
Sätt upp organisation, användare och behörigheter
Skapa organisationen hos oss och lägg upp team med samma behörighetsnivåer som i GitHub. Koppla inloggningen till er befintliga identitetsleverantör via OIDC om ni har en, annars lokala konton med tvingad tvåfaktor. Sätt branch-skyddet direkt — det är lätt att skjuta upp och det märks först när någon pushar till main.
- 3
Spegla repon och flytta ärendehistoriken
Migreringsverktyget hämtar repo, taggar, releaser, wiki, issues och pull requests via GitHub-API:t med en personlig åtkomsttoken. Kör en testmigrering av ett medelstort repo först och granska resultatet innan ni tar resten. LFS-objekt och containerimages i ghcr.io flyttas separat och följer inte med i samma pass.
- 4
Flytta hemligheter — och rotera dem samtidigt
Hemligheter kan inte läsas ut ur GitHub, så de måste sättas på nytt oavsett. Utnyttja det: rotera varje nyckel i samband med flytten i stället för att klistra in samma värden. Lägg dem på organisationsnivå där flera repon delar dem, och dokumentera vilken pipeline som behöver vilken.
- 5
Skriv om workflows och byt ut de actions som inte bär
Syntaxen i .gitea/workflows är i huvudsak densamma som GitHub Actions, så filerna kan oftast kopieras rakt av. Testa sedan varje workflow: vanliga actions som checkout, setup-node och cache fungerar normalt, medan de som anropar GitHubs eget API, använder OIDC-federation eller förutsätter GitHubs runner-image inte gör det. Lås versioner explicit och ersätt det som fallerar med rena skalsteg. Räkna med att det här steget tar mest tid av alla.
- 6
Kör båda systemen parallellt tills utfallen matchar
Behåll GitHub som spegel och pusha till båda remotes under en period. Jämför bygglogg mot bygglogg på samma commit — skillnader beror oftast på förinstallerade verktyg i runner-imagen, inte på er kod. Först när tio till femton körningar i rad ger samma resultat är det rimligt att göra vår CI till obligatorisk statuskontroll.
- 7
Peka om deploy-mål och webhooks, arkivera sedan GitHub
Uppdatera deploy-nycklar, containerregister och alla webhooks som pekar på github.com. Deployar pipelinen till vår App Hosting (från 99 kr/mån) räcker det med en deploy-nyckel och en webhook. Sätt GitHub-repona i arkiverat, skrivskyddat läge i stället för att radera dem — gamla permalänkar i dokumentation och ärenden slutar annars fungera. Behåll dem minst ett kvartal.
Vad som faktiskt är krångligt
- Marketplace-actions fungerar inte alltid oförändrat. Det som bara kör kommandon går bra; det som anropar GitHubs REST- eller GraphQL-API, använder OIDC-federation mot AWS eller GCP, eller förlitar sig på GitHubs runner-image, gör det inte. Testa varje action, lås versioner och räkna med att ersätta några med skalsteg.
- Runner-imagen är inte GitHubs ubuntu-latest. Pipelines som antar att ett verktyg redan finns installerat fallerar, ofta med ett kryptiskt fel långt in i bygget. Installera beroenden explicit i workflowet i stället för att lita på imagen.
- OIDC-federation mot molnleverantörer försvinner. Workflows som hämtar temporära AWS- eller GCP-credentials via GitHubs identitetsleverantör måste gå över till långlivade nycklar eller en annan mekanism. Det är en säkerhetsförsämring som ska hanteras medvetet, inte upptäckas i efterhand.
- Delar av GitHub har ingen motsvarighet: Codespaces, Advanced Security och kodskanning, Pages, Discussions och org-övergripande rulesets. Är något av det affärskritiskt är svaret inte att flytta allt, utan att flytta det som går och betala för resten.
- Ärendehistoriken följer med som text, men granskningstrådar i pull requests, statuskontrollernas historik och permalänkar till github.com gör det inte fullt ut. Länkar i gammal dokumentation pekar fortfarande dit — därför ska GitHub-repona arkiveras, inte raderas.
Kostnadsexempel
Ett team på tio utvecklare på GitHub Team ligger på cirka 40 USD per månad i licenser, alltså grovt 450 kr, plus det som CI-minuterna kostar utöver den inkluderade potten. För en aktiv monorepo med många parallella byggen blir CI-posten ofta större än licenserna. Priser och inkluderade volymer ändras löpande — kontrollera aktuell prislista. Motsvarande hos oss: Git och CI 199 kr/mån för tio användare. Behöver ni tunga parallella byggen dimensionerar vi en egen runner på en dedikerad server från 890 kr/mån, vilket fortfarande är förutsägbart i stället för rörligt.
Vanliga frågor
- Fungerar våra GitHub Actions-workflows rakt av?
- Filerna kan oftast kopieras utan ändring — syntaxen är densamma. Actions är en annan sak: de vanligaste fungerar, men de som pratar med GitHubs API eller använder OIDC-federation gör det inte. Räkna med att testa och justera varje workflow, inte med att lyfta över dem blint.
- Följer issues och pull requests med?
- Ja, migreringsverktyget hämtar issues, pull requests, releaser, taggar och wiki via GitHub-API:t. Granskningstrådar och statuskontrollernas historik blir inte identiska. Kör en testmigrering på ett repo och titta på resultatet innan ni bestämmer er för hela flytten.
- Kan vi behålla GitHub parallellt?
- Ja, och vi rekommenderar det under övergången. Git är distribuerat, så att pusha till två remotes är en rad i konfigurationen. Många behåller GitHub som skrivskyddad spegel permanent för publika repon.
- Vad händer med containerimages i ghcr.io?
- De flyttas separat. Paketregistret hos oss talar samma OCI-protokoll, så det handlar om att tagga om och pusha — plus att uppdatera alla pull-referenser i Kubernetes-manifest, compose-filer och deploy-skript. Glöm inte hemligheterna för imagehämtning.
- Har ni ISO 27001 eller SOC 2?
- Nej. Vi har varken ISO 27001, SOC 2 eller PCI-DSS. Det vi har är GDPR-efterlevnad med all data i EU, öppen källkod hela vägen ner så att ni kan granska vad som körs, och avtal som ger er uttag av data när ni vill. Har er upphandling ett certifieringskrav ska ni veta det innan projektet startar.
- Hur tar vi oss ur igen om det inte fungerar?
- Klona repona — de innehåller hela historiken. Issues och pull requests exporteras via API:t och workflow-filerna ligger redan i repot. Samma väg ut som in, vilket är poängen med öppna format.