Gruppmigreringar är den typen av ”enkla” uppgift som i tysthet äter upp hela veckan. Du börjar med ett GitLab-repo, inser att det finns 40 till, och lägger sedan timmar på att jaga namnkonflikter, strulande autentisering och det där projektet som alla glömde att det fanns.
DevOps-ansvariga fastnar ofta med jobbet. Men byråägare som flyttar kundarbete till en självhyst stack och produktteam som lämnar en hostad plan känner samma smärta. Den här GitLab Gitea migration-automationen flyttar en hel GitLab-grupp till en Gitea-organisation i en körning, samtidigt som den säkert hoppar över repos som redan finns.
Du får se vad workflowen gör, vad du behöver för att köra den, och var team brukar gå bet så att du kan migrera med trygghet och köra om senare för att fånga upp det som saknas.
Så fungerar automationsflödet
Se hur detta löser problemet:
n8n Workflow Template: GitLab till Gitea: migrera grupper utan krångel
flowchart LR
subgraph sg0["When clicking ‘Execute workflow’ Flow"]
direction LR
n0@{ icon: "mdi:play-circle", form: "rounded", label: "When clicking ‘Execute workf..", pos: "b", h: 48 }
n1@{ icon: "mdi:swap-vertical", form: "rounded", label: "Loop Over Items", pos: "b", h: 48 }
n2@{ icon: "mdi:swap-horizontal", form: "rounded", label: "Switch error codes", pos: "b", h: 48 }
n3@{ icon: "mdi:location-exit", form: "rounded", label: "Stop and Error", pos: "b", h: 48 }
n4@{ icon: "mdi:swap-vertical", form: "rounded", label: "Setup (CHANGE ME)", pos: "b", h: 48 }
n5["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/httprequest.dark.svg' width='40' height='40' /></div><br/>Gitea: Migrate repo"]
n6["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/httprequest.dark.svg' width='40' height='40' /></div><br/>Gitea: Search for repo"]
n7["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/httprequest.dark.svg' width='40' height='40' /></div><br/>Gitlab: Get projects"]
n1 --> n6
n4 --> n7
n2 --> n5
n2 --> n3
n5 --> n1
n7 --> n1
n6 --> n1
n6 --> n2
n0 --> n4
end
%% Styling
classDef trigger fill:#e8f5e9,stroke:#388e3c,stroke-width:2px
classDef ai fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
classDef aiModel fill:#e8eaf6,stroke:#3f51b5,stroke-width:2px
classDef decision fill:#fff8e1,stroke:#f9a825,stroke-width:2px
classDef database fill:#fce4ec,stroke:#c2185b,stroke-width:2px
classDef api fill:#fff3e0,stroke:#e65100,stroke-width:2px
classDef code fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
classDef disabled stroke-dasharray: 5 5,opacity: 0.5
class n0 trigger
class n2 decision
class n5,n6,n7 api
classDef customIcon fill:none,stroke:none
class n5,n6,n7 customIcon
Utmaningen: migrera GitLab-grupper utan manuellt repo-trassel
Att migrera en GitLab-grupp låter som en uppgift tills du gör det på det vanliga sättet. Du slutar med att kopiera clone-URL:er till ett kalkylblad, skapa repos ett i taget, och sedan upptäcka att mål-organisationen redan har ett repo med samma namn (eller värre: ett halv-migrerat repo från ett tidigare försök). Varje repo lägger till ännu en runda med behörigheter, token-testning och ”varför misslyckades just den här” felsökning. Och när du är klar litar du ändå inte riktigt på resultatet, så du gör en andra vända för att verifiera vad som flyttade och vad som inte gjorde det. Ärligt talat är det i den andra vändan som mest tid försvinner.
Det drar iväg snabbt. Här är var det brukar fallera.
- Du tappar timmar på repetitiv migrering repo för repo, särskilt när gruppen har dussintals projekt.
- Namnkrockar tvingar dig att stanna mitt i migreringen och bestämma vad som ska skrivas över, döpas om eller hoppas över.
- Delkörningar skapar röriga lägen, så en ”retry” känns riskabel i stället för rutin.
- Verifiering blir ett separat projekt, eftersom du saknar en tydlig regel för ”finns redan, hoppa över”.
Lösningen: migrera en GitLab-grupp till Gitea i en körning
Det här n8n-workflowet migrerar alla repositories från en specifik GitLab-grupp till en mål-organisation i Gitea genom att använda Giteas integrerade migrations-endpoint. Du startar det manuellt när du är redo, och det börjar med att läsa in en liten konfiguration (din GitLab-grupps namn, mål-organisationen i Gitea, plus tokens). Sedan hämtar den hela projektlistan från GitLab, loopar igenom varje repository i hanterbara batchar, och kontrollerar i Gitea om ett repo med samma namn redan finns. Om det finns hoppar workflowet över det. Om det inte finns triggar det en migrationsrequest i Gitea för det repot och fortsätter till nästa. När något går fel routar det felet och stoppar med ett tydligt fel i stället för att i tysthet missa projekt.
Workflowet startar med en manuell trigger. GitLab levererar listan med projekt, Gitea blir destinationen, och HTTP-anrop hanterar både kontrollen ”finns det?” och själva migrationsanropet. I praktiken får du en upprepad körning: migrera det som saknas, hoppa över det som redan finns, kör om senare utan oro.
Vad som förändras: före vs. efter
| Det här elimineras | Effekt du märker |
|---|---|
|
|
Effekt i verkligheten
Säg att din GitLab-grupp har 30 repositories. Manuellt ser till och med en ”snabb” process ofta ut som 10 minuter per repo för att skapa ett mål, verifiera namnet, köra en migrering och göra en rimlighetskontroll, vilket blir cirka 5 timmars fokuserat arbete (och vanligtvis mycket kontextväxling). Med det här workflowet lägger du cirka 15 minuter på att sätta tokens och grupp-/org-namn, och låter sedan körningen rulla medan du övervakar den. Om du kör om det i morgon hoppar det över repos som redan finns och migrerar bara det som fortfarande saknas, så du slipper upprepa samma rutinjobb.
Krav
- n8n-instans (prova n8n Cloud gratis)
- Självhosting om du föredrar (Hostinger fungerar bra)
- GitLab som källgrupp att migrera från.
- Gitea som mål-organisation att migrera till.
- GitLab personal access token (hämta i GitLab användarinställningar → Access Tokens).
- Gitea access token (hämta i Gitea användarinställningar → Applications).
Kompetensnivå: Medel. Du klistrar in tokens, redigerar en config-nod och verifierar API-behörigheter i GitLab och Gitea.
Behöver du hjälp att implementera detta? Prata med en automationsexpert (gratis 15-minuters konsultation).
Flödet i workflowet
Manuell start. Du klickar på ”Execute workflow” när du är redo att migrera. Det är avsiktligt, eftersom gruppmigreringar normalt är planerat arbete, inte något du vill att ska triggas vid varje nytt repo.
Konfiguration laddas. I steget ”Initialize Config” sätter du GitLab-gruppens slug, Gitea-organisationens namn och token-värden som används för anropen. Håll namnen URL-vänliga och kopiera dem från adressfältet, så slipper du kämpa med subtila namnavvikelser.
GitLab-projekt hämtas och batchas. Workflowet begär projektlistan från GitLab och loopar sedan igenom den med batchbearbetning så att stora grupper inte överbelastar någon sida med en burst av anrop.
Gitea kontrolleras, sedan körs migreringen. För varje projekt kontrollerar det om repot redan finns i mål-organisationen. Om inte triggar det Giteas migrationsverktyg för det repositoryt; om ja hoppas det över utan krångel och fortsätter.
Du kan enkelt ändra regeln ”finns/hoppa över” till att döpa om repos i stället för att hoppa över, beroende på behov. Se hela implementeringsguiden nedan för anpassningsalternativ.
Steg-för-steg-guide för implementering
Steg 1: konfigurera den manuella triggern
Starta arbetsflödet med en manuell trigger så att ni kan testa migreringsprocessen innan ni kör den i produktion.
- Lägg till noden Manual Launch Start som din trigger.
- Koppla Manual Launch Start till Initialize Config för att börja konfigurationssteget.
Tips: Manuella triggers är idealiska för att validera API-inloggningsuppgifter och migreringslogik innan ni automatiserar körningen.
Steg 2: anslut GitLab- och Gitea-tjänster
Konfigurera HTTP API-anslutningarna som används för att hämta GitLab-projekt och migrera dem till Gitea.
- Öppna Retrieve GitLab Projects och ställ in URL till
=https://gitlab.com/api/v4/groups/{{ $json.gitlabGroupPathName }}/projects. - I Retrieve GitLab Projects ställer ni in Query Parameters → per_page till
20. - Aktivera paginering i Retrieve GitLab Projects med Complete Expression satt till
={{ $response.headers['x-page'] == $response.headers['x-total-pages'] }}och parametern page satt till={{ $response.headers['x-next-page'] }}. - Inloggningsuppgift krävs: Anslut era httpHeaderAuth-inloggningsuppgifter till Retrieve GitLab Projects.
- Öppna Check Gitea Repository och ställ in URL till
=https://gitea.example.com/api/v1/repos/{{ $('Initialize Config').item.json.giteaOrganizationPathName }}/{{ $json.path }}. - Inloggningsuppgift krävs: Anslut era httpHeaderAuth-inloggningsuppgifter till Check Gitea Repository.
- Öppna Migrate to Gitea och ställ in URL till
=https://gitea.example.com/api/v1/repos/migratemed Method satt till POST. - Inloggningsuppgift krävs: Anslut era httpHeaderAuth-inloggningsuppgifter till Migrate to Gitea.
⚠️ Vanlig fallgrop: Gitea-bas-URL:en måste matcha er serverdomän exakt; URL:er som inte matchar ger 404-fel.
Steg 3: konfigurera inställningar och projektiterering
Definiera era identifierare för GitLab och Gitea, och batcha samt iterera igenom projekten.
- Öppna Initialize Config och ställ in gitlabAccessToken till
[CONFIGURE_YOUR_API_KEY]. - Ställ in gitlabGroupPathName till
[YOUR_ID]och giteaOrganizationPathName till[YOUR_ID]i Initialize Config. - Koppla Initialize Config till Retrieve GitLab Projects för att hämta projektlistan.
- Koppla Retrieve GitLab Projects till Iterate Project Batch för att behandla projekt i batchar.
- Koppla Iterate Project Batch till Check Gitea Repository för att verifiera om ett projekt redan finns i Gitea.
Tips: Använd en GitLab-access token med begränsat scope och read_api-behörighet för att undvika åtkomstfel när ni listar gruppens projekt.
Steg 4: konfigurera migreringsförfrågan
Använd projektdata från GitLab för att bygga migrerings-payloaden som skickas till Gitea.
- I Migrate to Gitea ställer ni in JSON Body till
={ "auth_token": "{{ $('Initialize Config').item.json.gitlabAccessToken }}", "clone_addr": "{{ $('Iterate Project Batch').item.json.http_url_to_repo }}", "description": "{{ $('Iterate Project Batch').item.json.description }}", "issues": true, "labels": true, "lfs": true, "milestones": true, "mirror": false, "private": true, "pull_requests": true, "releases": true, "repo_name": "{{ $('Iterate Project Batch').item.json.path }}", "repo_owner": "{{ $('Initialize Config').item.json.giteaOrganizationPathName }}", "service": "gitlab", "wiki": true }. - Säkerställ att Send Body är aktiverat och att Specify Body är satt till JSON i Migrate to Gitea.
- Koppla Route Error Status till Migrate to Gitea så att endast saknade repositories triggar migrering.
- Koppla Migrate to Gitea tillbaka till Iterate Project Batch för att fortsätta med nästa projekt.
Steg 5: lägg till felhantering
Hantera oväntade API-svar när ni kontrollerar om Gitea-repositories redan finns.
- I Route Error Status bekräftar ni att regeln kontrollerar att leftValue
={{ $json.error.status }}är lika med404. - Säkerställ att fallback-utgången routar till Abort With Error för andra fel än 404.
- I Abort With Error behåller ni Error Message satt till
Unexpected error code when checking if Gitea repo already exists.
⚠️ Vanlig fallgrop: Om Gitea-API:et returnerar 401 eller 403 kommer arbetsflödet att stoppa – verifiera att er httpHeaderAuth-token har tillräckliga behörigheter.
Steg 6: testa och aktivera ert arbetsflöde
Validera migreringsflödet med en manuell körning innan ni använder det regelbundet.
- Klicka på Execute Workflow för att köra Manual Launch Start och följ hur items flödar genom Retrieve GitLab Projects, Iterate Project Batch och Migrate to Gitea.
- Bekräfta lyckade körningar genom att kontrollera att nya repositories har skapats i Gitea och att inga fel hamnar i Abort With Error.
- När ni är nöjda sparar ni och aktiverar arbetsflödet för användning i produktion.
Se upp med
- GitLab-uppgifter kan löpa ut eller sakna nödvändiga scopes. Om anropet för projektlistan misslyckas, kontrollera först scopes för din GitLab Access Token i GitLabs användarinställningar.
- Om du använder Wait-noder eller extern rendering varierar processtiderna. Öka väntetiden om nedströmsnoder fallerar på tomma svar.
- Gitea-migreringar misslyckas ofta på grund av behörigheter eller fel format på Authorization-headern. Bekräfta att headern är exakt Authorization: token YOUR_TOKEN i n8n-credentialn som används av HTTP-noderna för ”Gitea”.
Vanliga frågor
Cirka 30 minuter om dina tokens är klara.
Ja, men de vill ha någon som är bekväm med API-tokens. Ingen kodning, bara noggrann konfiguration och testning.
Ja. n8n har ett gratis självhostat alternativ och en gratis provperiod på n8n Cloud. Cloud-planer börjar på 20 USD/månad för högre volym. Du behöver också räkna med hostingkostnader för GitLab och Gitea om du driver infrastrukturen själv.
Två alternativ: n8n Cloud (hanterat, enklast setup) eller självhosting på en VPS. För självhosting är Hostinger VPS prisvärt och klarar n8n bra. Självhosting ger obegränsat antal körningar men kräver grundläggande serveradministration.
Du kan justera värdena i ”Initialize Config” så att de pekar på en annan grupp eller organisation, och sedan tweaka logiken i ”Check Gitea Repository” så att den döper om i stället för att hoppa över när ett namn redan finns. Vissa team filtrerar också GitLabs projektlista så att bara vissa synlighetsnivåer migreras. En annan vanlig ändring är att först migrera bara en delmängd repos (en pilotbatch) och sedan ta bort filtret för hela körningen.
Oftast är det formatet på Authorization-headern eller en token utan tillräckliga behörigheter. Generera om din Gitea access token, uppdatera n8n Header Auth-credentialn och bekräfta att headern innehåller ordet ”token” före värdet. Om det fortfarande fallerar, kontrollera Gitea base URL som används av noden HTTP Request och säkerställ att du kan nå den endpointen från din n8n-server.
Den skalar bra för de flesta små och medelstora grupper, eftersom den bearbetar repositories i batchar i stället för allt på en gång.
För det här användningsfallet: oftast ja. Zapier och Make är bra för SaaS-liknande triggers, men gruppmigreringar behöver ofta loopar, grenlogik och beteendet ”kontrollera och agera” över många objekt, vilket n8n hanterar snyggt. Du får också självhosting som ett praktiskt alternativ när din GitLab och Gitea ligger i ett privat nätverk. Nackdelen är setup: du lägger mer tid på credentials och testning än med en enkel tvåstegs-Zap. Prata med en automationsexpert om du vill ha en snabb rekommendation för din miljö.
Du sätter upp detta en gång, och sedan slutar migreringar vara ett fruktat ”projekt” och blir en upprepbar körning. Låt workflowet ta hand om de tråkiga delarna så att du kan fokusera på cutovern, inte på copy-paste.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.