Fra GitHub til GitLab: gamle vedlegg kan bli igjen

Ved migrering fra GitHub til GitLab bør dere prøveimportere et representativt prosjekt og sammenligne resultatet med kilden før dere bytter arbeidssted. GitLabs dokumentasjon for GitHub-import opplyser at Markdown-bildevedlegg lastet opp til private repositorier før 9. mai 2023 ikke kan importeres. Andre private vedlegg kan også feile når SAML-SSO hindrer nedlasting. En vellykket overføring av kodehistorikken er derfor ikke en fullstendig migreringskontroll.

Velg GitLabs GitHub-import når saker, pull requests, kommentarer og annen prosjekthistorikk skal følge med. Velg speiling av Git-referanser når dere bare trenger repositoriet, og håndter Git LFS-objekter særskilt. Begge metodene trenger en plan for siste endringer i GitHub og en kontroll av at innholdet faktisk kan brukes i GitLab.

Bestem hva som skal følge prosjektet

Lag en oversikt per repositorium over grener, tagger, aktive saker, pull requests, kommentarer, Markdown-vedlegg og filer lagret med Git LFS. Noter også hvem som skal ha tilgang, og hvilke byggjobber eller integrasjoner som bruker den gamle prosjektadressen. Da har dere et konkret sammenligningsgrunnlag når importstatusen viser at arbeidet er ferdig.

GitLabs GitHub-import kan hente blant annet Git-data, saker, pull requests, kommentarer, LFS-objekter og wiki-sider. Markdown-vedlegg fra kommentarer, saksbeskrivelser, pull request-beskrivelser og utgivelsesnotater må derimot velges særskilt ved import; ellers kan lenkene slutte å virke når vedleggene fjernes fra GitHub. GitHub-organisasjoner blir ikke opprettet som GitLab-grupper gjennom prosjektimporten. Opprett derfor gruppestrukturen og bestem måladressene før dere importerer prosjektene.

For GitHub.com kan importen startes i GitLabs grensesnitt med GitHub OAuth eller tilgangstoken, eller via import-API-et. Et selvhostet GitHub Enterprise Server må importeres via API-et. Hvis dere bruker et GitHub-token og prosjektet har LFS-filer eller dere vil importere samarbeidspartnere, må tokenets tilganger også dekke dette. Bruk samme metode og tilganger i prøveflyttingen som dere planlegger å bruke ved den endelige overgangen.

Skill prosjektimport fra Git-speiling

Et Git-speil overfører Git-referanser og historikk, men tar ikke med saker, diskusjoner eller vedlegg som GitHub lagrer utenfor repositoriet. For et repositorium med LFS beskriver GitHubs fremgangsmåte for speiling en egen overføring av objektene: Kjør git lfs fetch --all etter kloning, speil Git-referansene med git push --mirror, og send deretter objektene med git lfs push --all til målrepositoriet. Bruk adressen til GitLab-prosjektet som mål. En vellykket Git-push alene viser ikke at filinnholdet bak LFS-pekerne er tilgjengelig der.

GitLabs importør er det naturlige valget når sakshistorikken skal bevares, men også den krever kontroll av resultatet. Importstatus kan vise at enkelte elementer feilet, og detaljvisningen kan brukes til å finne dem. Sammenlign dessuten faktiske saker og filer: Et riktig antall saker sier lite om et bilde i en gammel kommentar kan åpnes, eller om en LFS-fil lar seg hente i en ny klone.

Bruk prøveflyttingen til å finne avvik

Velg et privat prosjekt som faktisk inneholder datatypene dere er avhengige av: eldre bilder i saker, kommentarer fra flere bidragsytere og LFS-filer hvis slike finnes. Importer det til en egen GitLab-gruppe. En enkel kodebase uten vedlegg kan gi en vellykket prøveimport uten å avdekke problemene som betyr mest i den endelige flyttingen.

Registrer grener, tagger og siste commit på aktive grener i GitHub. Ta med antall åpne og lukkede saker og pull requests, og noter konkrete vedleggslenker som skal prøves etterpå.
Kjør importen med planlagte valg for Markdown-vedlegg og samarbeidspartnere. Les importstatusen og detaljene for elementer som feilet.
Åpne et utvalg gamle og nye saker i GitLab. Sammenlign beskrivelser, kommentarer, bilder, henvisninger og tilordnede personer med GitHub.
Klone GitLab-prosjektet på nytt og åpne et utvalg filer som bruker LFS. Registrer avvik, ansvarlig for retting og hvilke avvik som må stoppe overgangen.

Behandle private vedlegg som en egen kontroll, særlig hvis den gamle GitHub-tilgangen skal stenges. Ved SAML-SSO på GitHub-siden kan importbrukeren trenge tilgang som ekstern samarbeidspartner i kilderepositoriet for å hente private vedlegg. Bilder som omfattes av begrensningen for eldre private opplastinger, må håndteres manuelt hvis de skal bevares i GitLab. Kontroller den nye lenken etter at filen er lagt inn; en lenke som fortsatt peker til GitHub, er avhengig av at innholdet forblir tilgjengelig der.

Kontroller brukere og rettigheter

Importer bidrag og medlemskap kan først knyttes til plassholderbrukere. GitLabs veiledning om brukertilordning beskriver hvordan bidrag og medlemskap deretter kan knyttes til riktige GitLab-kontoer, også når e-postadressene er ulike. Ved import til en personlig navneplass knyttes alle bidrag til eieren og kan ikke tilordnes på nytt. Velg derfor en gruppenavneplass hvis korrekt historisk tilordning er viktig.

Gå gjennom tidligere ansatte, botkontoer og bidragsytere med ulike brukernavn på de to plattformene før dere godkjenner tilordningen. Kontroller medlemskap og nåværende tilgang separat fra historisk forfatterskap. Hvis GitLab.com-gruppen bruker SAML-SSO, må brukerne ha knyttet SAML-identiteten til GitLab-kontoen sin. Prøveflyttingen bør vise hvem som må gjøre dette før den endelige importen.

Frys endringer og behold en vei tilbake

Avtal når nye commits, saker og kommentarer skal stoppe i GitHub. En oppdatert Git-speiling kan ta med nye Git-referanser, men den synkroniserer ikke nye saksdiskusjoner etter prosjektimporten. Hvis en full skrivefrys ikke er mulig, må en navngitt ansvarlig registrere endringer i overgangsvinduet og kontrollere at hver av dem er håndtert i GitLab.

Kjør den endelige importen eller siste speiling etter frysen. Sammenlign aktive grener, tagger og siste commits med kontrollgrunnlaget, og gå deretter gjennom saker, kommentarer, vedlegg, LFS-filer og brukertilordninger. Oppdater fjernadresser, automatisering og prosjektlenker først når avvikene er vurdert. Behold GitHub-prosjektet tilgjengelig i en avtalt overgangsperiode: Hvis viktige data mangler, kan teamet fortsette der mens feilen undersøkes. En ny GitLab-import oppretter en ny kopi av kildeprosjektet og må kontrolleres som en egen flytting.

Les også: