Migreringsguide · Fra GitHub
Migrer fra GitHub til SIAX Git og CI
GitHub er ikke et dårlig verktøy, og det er sjelden grunnen til at noen flytter. Grunnene er som regel tre: lisenskostnaden per utvikler som vokser med teamet, CI-minutter som er vanskelige å forutsi, og at både koden og byggkjeden ligger under amerikansk jurisdiksjon. For selskaper som selger til offentlig sektor eller regulerte kunder, er ofte det siste argumentet det som avgjør.
Vår Git og CI er selvhostet Gitea med Actions-kompatible runnere, alt i EU. Git-protokollen er den samme, så kloner, remotes og verktøy fungerer uendret, og workflow-syntaksen er i hovedsak den samme som GitHub Actions. Prisen er 199 kr/mnd for ti brukere, mot lisens per utvikler pluss variabel CI-kostnad.
Den ærlige advarselen: Actions-kompatibiliteten er god, men ikke identisk. Workflow-filene kan som regel kopieres rett over, men enkelte marketplace-actions må byttes ut, og deler av GitHubs økosystem — Codespaces, Advanced Security, Pages, OIDC-føderasjon mot skyleverandører — har ingen erstatning. Denne guiden legger tiden der arbeidet faktisk ligger: i pipelinen, ikke i koden.
Tidsbruk
En halv dag for et repo med en enkel pipeline. For 20–30 repoer med aktive workflows: regn med to til tre arbeidsdager, der mesteparten går med til å teste om workflows — ikke til å flytte kode.
Nedetid
Ingen for koden. Git er distribuert og alle har fullstendige kloner, så selve repoflyttingen merkes ikke. CI har derimot et gap: under omskrivingen finnes det en periode der bygget bare er verifisert på ett av systemene. Kjør begge parallelt til utfallene stemmer overens, før dere gjør vår CI obligatorisk.
Slik gjør du det
- 1
Kartlegg repoer, workflows og integrasjoner
List opp alle repoer med siste commit, størrelse og om de bruker LFS. Gå gjennom hvert aktive workflow og noter hvilke actions det bruker, hvilke hemmeligheter det leser, og hva det deployer til. Noter også alt som ligger utenfor Git: GitHub Apps, webhooks, branch-beskyttelse, kodeeiere og obligatoriske statuskontroller. Den listen er den reelle kravspesifikasjonen deres — ikke repolisten.
- 2
Sett opp organisasjon, brukere og tilganger
Opprett organisasjonen hos oss og legg opp team med de samme tilgangsnivåene som i GitHub. Koble innloggingen til den eksisterende identitetsleverandøren deres via OIDC hvis dere har en, ellers lokale kontoer med tvungen tofaktor. Sett branch-beskyttelsen med én gang — det er lett å utsette, og det merkes først når noen pusher til main.
- 3
Speil repoer og flytt sakshistorikken
Migreringsverktøyet henter repo, tagger, releaser, wiki, issues og pull requests via GitHub-API-et med en personlig tilgangstoken. Kjør en testmigrering av et middels stort repo først, og gjennomgå resultatet før dere tar resten. LFS-objekter og containerimages i ghcr.io flyttes separat og følger ikke med i samme omgang.
- 4
Flytt hemmeligheter — og roter dem samtidig
Hemmeligheter kan ikke leses ut av GitHub, så de må uansett settes på nytt. Utnytt det: roter hver nøkkel i forbindelse med flyttingen i stedet for å lime inn de samme verdiene. Legg dem på organisasjonsnivå der flere repoer deler dem, og dokumenter hvilken pipeline som trenger hvilken.
- 5
Skriv om workflows og bytt ut actions som ikke holder mål
Syntaksen i .gitea/workflows er i hovedsak den samme som GitHub Actions, så filene kan som regel kopieres rett over. Test deretter hvert workflow: vanlige actions som checkout, setup-node og cache fungerer normalt, mens de som kaller GitHubs eget API, bruker OIDC-føderasjon eller forutsetter GitHubs runner-image, ikke gjør det. Lås versjoner eksplisitt og erstatt det som feiler, med rene skallsteg. Regn med at dette steget tar mest tid av alle.
- 6
Kjør begge systemene parallelt til utfallene stemmer overens
Behold GitHub som speil og push til begge remotes i en periode. Sammenlign byggelogg mot byggelogg på samme commit — forskjeller skyldes som regel forhåndsinstallerte verktøy i runner-imaget, ikke koden deres. Først når ti til femten kjøringer på rad gir samme resultat, er det rimelig å gjøre vår CI til en obligatorisk statuskontroll.
- 7
Pek om deploy-mål og webhooks, arkiver deretter GitHub
Oppdater deploy-nøkler, containerregister og alle webhooks som peker til github.com. Deployer pipelinen til vår App Hosting (fra 99 kr/mnd), holder det med en deploy-nøkkel og en webhook. Sett GitHub-repoene i arkivert, skrivebeskyttet modus i stedet for å slette dem — gamle permalenker i dokumentasjon og saker slutter ellers å fungere. Behold dem i minst ett kvartal.
Hva som faktisk er vrient
- Marketplace-actions fungerer ikke alltid uendret. Det som bare kjører kommandoer, går bra; det som kaller GitHubs REST- eller GraphQL-API, bruker OIDC-føderasjon mot AWS eller GCP, eller er avhengig av GitHubs runner-image, gjør det ikke. Test hver action, lås versjoner og regn med å erstatte noen med skallsteg.
- Runner-imaget er ikke GitHubs ubuntu-latest. Pipelines som antar at et verktøy allerede er installert, feiler, ofte med en kryptisk feil langt inne i bygget. Installer avhengigheter eksplisitt i workflowet i stedet for å stole på imaget.
- OIDC-føderasjon mot skyleverandører forsvinner. Workflows som henter midlertidige AWS- eller GCP-credentials via GitHubs identitetsleverandør, må gå over til langlevde nøkler eller en annen mekanisme. Det er en sikkerhetsforverring som skal håndteres bevisst, ikke oppdages i ettertid.
- Deler av GitHub har ingen erstatning: Codespaces, Advanced Security og kodeskanning, Pages, Discussions og organisasjonsomfattende rulesets. Er noe av dette forretningskritisk, er svaret ikke å flytte alt, men å flytte det som går, og betale for resten.
- Sakshistorikken følger med som tekst, men gjennomgangstråder i pull requests, historikken til statuskontrollene og permalenker til github.com gjør det ikke fullt ut. Lenker i gammel dokumentasjon peker fortsatt dit — derfor skal GitHub-repoene arkiveres, ikke slettes.
Kostnadseksempel
Et team på ti utviklere på GitHub Team ligger på rundt 40 USD per måned i lisenser, altså grovt 450 kr, pluss det CI-minuttene koster utover den inkluderte potten. For et aktivt monorepo med mange parallelle bygg blir CI-posten ofte større enn lisensene. Priser og inkluderte volumer endres fortløpende — kontroller gjeldende prisliste. Tilsvarende hos oss: Git og CI 199 kr/mnd for ti brukere. Trenger dere tunge parallelle bygg, dimensjonerer vi en egen runner på en dedikert server fra 890 kr/mnd, som fortsatt er forutsigbart i stedet for variabelt.
Ofte stilte spørsmål
- Fungerer GitHub Actions-workflowene våre rett over?
- Filene kan som regel kopieres uten endring — syntaksen er den samme. Actions er en annen sak: de vanligste fungerer, men de som snakker med GitHubs API eller bruker OIDC-føderasjon, gjør det ikke. Regn med å teste og justere hvert workflow, ikke med å løfte dem over blindt.
- Følger issues og pull requests med?
- Ja, migreringsverktøyet henter issues, pull requests, releaser, tagger og wiki via GitHub-API-et. Gjennomgangstråder og historikken til statuskontrollene blir ikke identiske. Kjør en testmigrering på ett repo og se på resultatet før dere bestemmer dere for hele flyttingen.
- Kan vi beholde GitHub parallelt?
- Ja, og vi anbefaler det under overgangen. Git er distribuert, så å pushe til to remotes er én linje i konfigurasjonen. Mange beholder GitHub som skrivebeskyttet speil permanent for offentlige repoer.
- Hva skjer med containerimages i ghcr.io?
- De flyttes separat. Pakkeregisteret hos oss snakker samme OCI-protokoll, så det handler om å tagge om og pushe — pluss å oppdatere alle pull-referanser i Kubernetes-manifester, compose-filer og deploy-skript. Ikke glem hemmelighetene for imagehenting.
- Har dere ISO 27001 eller SOC 2?
- Nei. Vi har verken ISO 27001, SOC 2 eller PCI-DSS. Det vi har, er GDPR-etterlevelse med all data i EU, åpen kildekode hele veien ned slik at dere kan inspisere hva som kjører, og avtaler som gir dere uttrekk av data når dere vil. Har anskaffelsen deres et sertifiseringskrav, skal dere vite det før prosjektet starter.
- Hvordan kommer vi oss ut igjen hvis det ikke fungerer?
- Klon repoene — de inneholder hele historikken. Issues og pull requests eksporteres via API-et, og workflow-filene ligger allerede i repoet. Samme vei ut som inn, som er hele poenget med åpne formater.