Jak migrovat z Gitea na Forgejo, aniž byste rozbili své repozitáře

Zastavíte Gitea, nainstalujete Forgejo, zkopírujete app.ini a datový adresář a spustíte službu způsobem, který popisuje každý migrační návod. Webové UI se rozjede. Pak selže migrace databáze, nebo ještě hůř, Forgejo odmítne start, protože verze vašeho schématu je pro něj příliš nová na to, aby jí rozumělo. Máte Gitea 1.23 nebo novější a jednoduchý upgrade na místě, který všichni popisují, se na vás už nevztahuje.

Forgejo se na začátku roku 2024 stalo tvrdým forkem Gitea a od té doby se oba projekty rozešly i na úrovni schématu databáze. Jak migrovat z Gitea na Forgejo dnes zcela závisí na vaší verzi Gitea. Tento průvodce vám dá přesnou cestu pro vaši verzi, kompletní příkazy pro nativní i Docker instalace, řešení pro Gitea 1.23+ a ověřovací seznam, takže migrujete bez ztráty repozitářů, issues nebo uživatelů.

Stručně

• Verzní propast je reálná. Forgejo v10.0 byl posledním releasem podporujícím transparentní přímý upgrade z Gitea. Gitea v1.22 je nejvyšší verze, která může projít podporovanou přímou cestou.
• Na Gitea v1.22 nebo starší: nejprve migrujte na Forgejo v10.0.x, poté upgradujte Forgejo v10 na aktuální release (v15). Dva mezikroky, oba podporované.
• Na Gitea v1.23 nebo novější: neexistuje oficiálně podporovaná přímá cesta. Vybíráte mezi downgradem SQL/schématu, komunitními migračními skripty, migrací přes repozitář/API nebo přípravou na novém serveru pomocí jedné z těchto metod. Každá s sebou nese jiný kompromis ve ztrátě dat.
• Než se čehokoli dotknete, zálohujte svůj datový adresář a databázi. Každá cesta níže předpokládá, že máte obnovitelnou zálohu. U nepodporovaných cest to platí dvojnásob.
• Některé věci si vždy vyžádají pozornost po migraci: počítejte s tím, že budete muset znovu vytvořit nebo zkontrolovat osobní přístupové tokeny, znovu zaregistrovat runnery pro Actions a smazat a znovu vybudovat vyhledávací index Bleve. S tímto počítejte bez ohledu na zvolenou cestu.
• Migrace není povinná. Gitea je aktivně udržovaná. Rozhodnutí "zůstat na Gitea" dává smysl, pokud riziko migrace ve vaší situaci převažuje nad přínosem.

Mimo rozsah tohoto článku: migrace z Gogs, GitHub nebo GitLab na Forgejo a nastavení Forgejo Actions od nuly.

Předpoklady / co budete potřebovat

Než spustíte jediný příkaz, ověřte, že máte kompletní, obnovitelnou zálohu dvou věcí: datového adresáře Gitea (/var/lib/gitea při výchozí nativní instalaci) a databáze. Pokud je vaše databáze SQLite, tento soubor se nachází uvnitř datového adresáře; pokud jde o PostgreSQL nebo MySQL, zálohujte ji samostatně pomocí pg_dump nebo mysqldump. Migrace bez ověřené zálohy není migrace, je to hazard.

Budete také potřebovat:

• Vaši aktuální verzi Gitea. Spusťte gitea --version (nebo docker exec <container> gitea --version). Toto číslo určuje celou vaši cestu.
• Váš typ databáze: SQLite, PostgreSQL nebo MySQL. Některá řešení jsou specifická pro konkrétní databázi.
• Přístup root nebo sudo na serveru.
• Uvědomění, že podporovaná cesta instaluje Forgejo v10.0 jako mezikrok. Forgejo v10.0 je EOL od 16. dubna 2025. Instalujete ho jen na dobu migrace a hned poté z něj upgradujete pryč.

Proč se přímá cesta upgradu rozbila

V prosinci 2024 projekt Forgejo zveřejnil prohlášení o kompatibilitě vytyčilo jasnou hranici: "Budoucí verze Forgejo nebudou podporovat upgrady z instancí Gitea běžících ve verzi v1.23 nebo vyšší." Tato věta je celý problém v jednom řádku.

Když se Forgejo na začátku roku 2024 odštěpilo od Gitea, obě kódové báze se dál rozcházely a databázová schémata se od sebe vzdalovala. Forgejo udržovalo okno kompatibility, aby stávající provozovatelé Gitea mohli přejít, ale toto okno mělo konec. Forgejo v10.0, vydané 16. ledna 2025, bylo "the last version to allow a transparent upgrade from Gitea v1.22 or lower." Cokoliv novějšího než v10.0 nepřečte databázi Gitea přímo.

Lidi zaskočí právě načasování. Gitea v1.23 vyšla koncem roku 2024 a aktuální release Gitea k červnu 2026 je v1.26.4. Pokud jste svou instanci Gitea udržovali relativně aktuální, jste už za touto hranicí a standardní návody už váš případ nepopisují.

Shrnutí sekce: podporovaná přímá cesta končí u Gitea v1.22. Vše novější vyžaduje navíc jeden krok.

Najděte svou migrační cestu podle verze Gitea

Spusťte gitea --version, najděte svůj řádek a postupujte podle cesty ve třetím sloupci. Vše ostatní v tomto průvodci je jen detail k těmto řádkům.

Prohlášení o kompatibilitě verzí pocházejí přímo z oficiální oznámení Forgejo o kompatibilitě: Gitea do v1.21 lze přesunout na Forgejo v7.0 až v10.0 a Gitea v1.22 lze přesunout na Forgejo v8.0 až v10.0. Obě varianty končí u v10.0 jako posledního podporovaného přímého cíle.

Pod otázkou verze se skrývají tři migrační strategie a je užitečné je vidět ještě před podrobnými kroky:

• Na místě, na stejném serveru. Vyměňte binárku nebo image kontejneru na stávajícím boxu. Nejnižší úsilí, pokud to vaše verze podporuje; vyžaduje mezikrok přes v10.0.
• Příprava na čistém serveru. Připravte nový server a použijte ho jako bezpečný cíl pro migrační metodu odpovídající vaší verzi Gitea. Tím ochráníte původní server s Gitea a usnadníte návrat zpět, ale problém s databázovým schématem v Gitea 1.23+ to neobejde.
• Migrace přes repozitář/API. Použijte migrační nástroje Forgejo ke stažení repozitářů ze staré instance Gitea. Historie git je spolehlivá část; metadata jako issues, PR, štítky, releases, data wiki a komentáře berte jako snahu v mezích možností a ověřte je repozitář po repozitáři.

Podporovaná cesta: Gitea v1.22 nebo starší

Pokud máte Gitea v1.22 nebo starší, oficiální migrační dokumentace popisují dvoukrokovou cestu: migrujte na Forgejo v10.0.x, poté upgradujte Forgejo v10 na aktuální release. První krok je přímá výměna, protože Forgejo v10.x umí číst databázi Gitea v1.22; druhý krok je běžný upgrade Forgejo.

Existují dva způsoby, jak to udělat, podle toho, jak Gitea na vašem serveru běží. Vyberte ten, který odpovídá vašemu stávajícímu nastavení. Pokud Gitea běží jako systémová služba, použijte nativní cestu. Pokud Gitea běží v kontejneru, použijte cestu s Docker. Forgejo v10.x funguje jako přímá náhrada za Gitea v1.22.x.

Nativní cesta (systemd)

Nejprve zálohujte. Poté nainstalujte Forgejo v10.0.x pomocí balíčku vaší distribuce nebo release binárky pevně nastavené na v10.0. Před kopírováním čehokoli zastavte Gitea. Běžící služba zapisující do datového adresáře uprostřed kopírování kopii poškodí.

# Stop the running Gitea service before touching its data
systemctl stop gitea

Zkopírujte konfiguraci a datový adresář do umístění Forgejo a poté opravte vlastnictví. Konfigurační soubor musí být čitelný pro skupinu forgejo; data musí vlastnit uživatel forgejo.

# Copy the existing Gitea config to Forgejo's config path
cp /etc/gitea/app.ini /etc/forgejo/app.ini

# Back up the copied config before rewriting paths
cp /etc/forgejo/app.ini /etc/forgejo/app.ini.bak

# Update old Gitea data paths to Forgejo data paths
sed -i 's#/var/lib/gitea#/var/lib/forgejo#g' /etc/forgejo/app.ini

# Forgejo reads its config as the forgejo group; grant group write
chown root:forgejo /etc/forgejo/app.ini && chmod g+w /etc/forgejo/app.ini

# Copy the data directory and hand ownership to the forgejo user
rsync -aHAX --numeric-ids /var/lib/gitea/ /var/lib/forgejo/
chown -R forgejo:forgejo /var/lib/forgejo

Spusťte Forgejo a povolte jeho spouštění při startu systému.

# Start Forgejo and enable it at boot
systemctl start forgejo && systemctl enable forgejo

Než upgradujete z v10.0, vyprázdněte fronty, aby se během přechodu na novou verzi neztratila rozpracovaná práce.

# Flush pending queue items before the version upgrade
forgejo manager flush-queues

Nyní upgradujte Forgejo v10.0.x na aktuální release nahrazením binárky verzí v15 a restartováním služby podle standardního Průvodce upgradem Forgejo. Po obou krocích spusťte doctor, aby zkontroloval databázi a opravil, co dokáže.

# Check everything; write a log you can read if something is wrong
forgejo doctor check --all --log-file /tmp/doctor.log

Přečtěte si /tmp/doctor.log než použijete jakoukoli automatickou opravu. Použijte --fix pouze tehdy, když výstup doktora identifikuje konkrétní opravu, které rozumíte, nebo když postupujete podle oficiálního postupu řešení problémů.

Pokud doctor nehlásí žádné kritické chyby a webové rozhraní zobrazuje vaše repozitáře, je první migrace dokončena.

Cesta přes Docker / kontejner

Pokud Gitea běželo jako kontejner, spusťte Forgejo stejným způsobem. Použijte image Forgejo v10.x jako přímou náhradu svého image Gitea v1.22.x a namiřte ho na stejný datový svazek a databázi. Nejprve ověřte, že vaše verze Dockeru je alespoň 20.10.6. Starší verze způsobují u kontejnerů Forgejo nedefinované chování.

Jedna specifická věc týkající se kontejnerů, na které lidé zakopávají: proměnné prostředí. Forgejo si kvůli kompatibilitě ponechává předponu GITEA_, ale dokumentace doporučuje předávat obě předpony, aby vaše konfigurace přežila budoucí verzi Forgejo, která stará jména odstraní.

# docker-compose.yml (excerpt): pass both prefixes for forward compatibility
environment:
  - GITEA__database__DB_TYPE=postgres
  - FORGEJO__database__DB_TYPE=postgres
  # ...repeat the dual-prefix pattern for every config override you pass

U rootless kontejnerů musí data vlastnit uživatel 1000 a skupina 1000, odpovídající runtime uživateli rootless image. Poté, co se kontejner spustí na v10.x, spusťte stejný forgejo doctor check --all zevnitř kontejneru, poté upgradujte tag image na aktuální release v15 a restartujte.

Pokud máte Gitea v1.23 nebo novější

Tady standardní návody končí a tady se ve skutečnosti nachází většina aktuálních instalací. Pro Gitea v1.23+ neexistuje oficiálně podporovaná přímá cesta, takže každá z níže uvedených možností je buď komunitní, nebo ztrátová. Než kteroukoli z nich spustíte, vytvořte plnou zálohu svého datového adresáře i databáze a ověřte, že ji dokážete obnovit. Tyto postupy mění produkční data; záloha je vaše jediné tlačítko zpět.

Tyto tři možnosti se liší mírou rizika a tím, kolik toho zachovají. Vyberte tu, jejíž kompromis dokážete přijmout.

Možnost A: downgrade SQL schématu / patch verze

Nejužší řešení sníží verzi databázového schématu tak, aby ho Forgejo v10 bralo jako databázi v1.22.

Poznámka: neberte aktualizaci verze samu o sobě jako kompletní downgrade. Zaznamenaná verze migrace a skutečné schéma se musí shodovat. U Gitea 1.23.x nejprve otestujte celý downgrade na kopii a porovnejte schéma, než na ni namíříte Forgejo.

Jeden ze správců Forgejo popsal SQL v Codeberg issue #7638:

-- Downgrade the recorded schema version to the v1.22 baseline (PostgreSQL/MySQL)
UPDATE version SET version=305 WHERE id=1;

Poté pokračujete podle podporované cesty, jako byste byli na v1.22. Zásadní upozornění: správce toto potvrdil konkrétně jen pro Gitea v1.23.1, ne pro celou řadu v1.23.x. Číslo verze schématu je přesné; použití nesprávné cílové hodnoty na nesprávný release Gitea může databázi dostat do stavu, ze kterého ji žádná migrace nezachrání. Toto platí pro PostgreSQL/MySQL, není to oficiálně podporováno a není to testováno jako obecný postup.

Tip: Přímé nastavení version=305 přeskočí migraci 304 na 305, která změnila způsob kódování TOTP tajemství. Codeberg issue #8210 dokumentuje, že to poškozuje dvoufaktorové ověřování u dotčených uživatelů. Oprava spočívá v nastavení verze na 304 a spuštění migrace, nebo ve vymazání řádků tabulky two_factor, aby se uživatelé znovu zaregistrovali. Toto nevynechávejte, pokud jakýkoli účet používá TOTP.

Možnost B: postupné downgrade skripty SQL (Gitea 1.24 až 1.25.2)

U verzí mezi 1.24 a 1.25.2 nestačí jediný verzní patch: schéma prošlo několika mezistavy. Komunitní skripty na xlrl/prepare-gitea-migration-to-forgejo provedou schéma zpět přes mezilehlé verze až na v1.22, po čemž následuje podporovaná cesta. Tyto skripty jsou komunitní práce, ne oficiální postup, a jako hlavní případ cílí na SQLite. Spouštějte je pouze proti databázi, kterou jste již zálohovali.

Možnost C: migrace přes API repozitář po repozitáři (Gitea 1.26+ nebo jakákoli verze)

Cesta přes repozitář/API zachovává data Git nejspolehlivěji. V závislosti na zdroji, oprávněních a migrační metodě mohou být k dispozici i volitelná metadata jako issues, pull requesty, štítky, milníky, releases, data wiki a komentáře, ale berte to jako snahu v mezích možností a ověřte to repozitář po repozitáři. Pro archiv pouze kódu to obvykle stačí; pro server, kde je issue tracker pamětí týmu, otestujte přenos metadat, než se na tuto cestu zavážete.

Dva experimentální nástroje se pokoušejí o úplnější migrace pro 1.23+, ale mají vlastní mezery. pacnpal/gitea2forgejo (GitHub) provede kompletní dump a synchronizaci přes API a vyžaduje odpovídající SECRET_KEY pro přenos zašifrovaných polí, ale nepřenáší Personal Access Tokens, Actions runnery, callback URL webhooků ani 2FA. nicoverbruggen/gitea-to-forgejo (GitHub) je experimentální nástroj založený na Podman, který přenáší uživatele, klíče, organizace, repozitáře, issues, PR, releases a mirrory, ale ne 2FA tokeny, runtime data Actions ani osamocené manifesty OCI balíčků. Oba nástroje považujte za experimentální a výsledek ověřte podle přenosové matice níže.

Shrnutí sekce: pro Gitea 1.23+ neexistuje oficiálně podporovaná přímá cesta. Vyberte možnost, s jejíž mírou ztráty dat dokážete žít, a před začátkem zálohujte.

Migrace na čistém serveru je bezpečnější, ale neobchází verzní hranici

Čistý server je nejbezpečnější místo pro přípravu a ověření migrace, ale nejde o samostatnou cestu kompatibility schémat. Pokud je vaším zdrojem Gitea v1.22 nebo starší, nainstalujte na cílový server nejprve Forgejo v10.0.x, obnovte nebo zkopírujte tam data z Gitea, nechte Forgejo provést podporované migrace databáze a poté tuto instanci Forgejo v10 upgradujte na aktuální release Forgejo.

Pokud je vaším zdrojem Gitea v1.23 nebo novější, neobnovujte databázi Gitea přímo do aktuálního Forgejo s očekáváním, že se spustí. Stále potřebujete jeden z výše uvedených nepodporovaných postupů pro 1.23+: postupný SQL downgrade nebo revert, komunitní migrační nástroj, nebo migraci přes repo/API. Čistý server snižuje riziko při případném návratu zpět, protože původní server s Gitea zůstane nedotčen; neodstraňuje ale potřebu vyřešit nesoulad verze databáze.

Tady je to místo, kde Forgejo od Cloudzy na jedno kliknutí aplikace může pomoct: použijte ji jako čistou cílovou instanci a poté spusťte migrační metodu odpovídající vaší verzi Gitea. Marketplace image Cloudzy vám dá připravený cíl Forgejo na našem výkonném VPS, takže se můžete soustředit na obnovu, ověření a přepnutí místo počáteční instalace. Plán migrace stále závisí na tom, zda jste před nebo za hranicí Gitea 1.22.

Co se přenáší a co musíte udělat znovu

Některá vaše data se přenesou automaticky, jiná pouze za splnění podmínky a některá se nepřenesou nikdy a musí se vytvořit ručně. Vědět předem, co je co, je rozdíl mezi hladkým přechodem a týdnem zmatených uživatelů.

Nejvíc zabolí čtyři věci, protože se rozbijí tiše nebo ovlivní každého uživatele, takže je řešte cíleně: uživatelé by si měli znovu vytvořit nebo zkontrolovat své Personal Access Tokens, musíte znovu zaregistrovat své Actions runnery proti novému hostname, musíte smazat vyhledávací index Bleve, aby ho Forgejo znovu čistě vybudovalo, a musíte přepsat jakékoli uses: krátké odkazy ve vašich workflow Actions na plné URL adresy GitHub, protože Forgejo a Gitea stahují akce ze samostatných zrcadel a relativní odkaz se vyhodnotí na špatné místo.

Tip: Pokud během migrace provozujete Gitea a Forgejo souběžně a obě míří na stejnou instanci Redis, nastavte Forgejo před začátkem na Redis db=1. Obě výchozí nastavení používají db=0, a pokud ho sdílejí, Gitea spotřebuje migrační události Forgejo a zničí frontu migrace. (blog.mei-home.net documents this exact failure.)

Shrnutí sekce: osobní přístupové tokeny, runnery pro Actions, deploy klíče pro jednotlivé repozitáře a vyhledávací index Bleve je vždy nutné řešit ručně. Naplánujte si je jako migrační úkoly, ne jako dodatečnou myšlenku.

Ověřte, že migrace proběhla úspěšně

Začněte doktorem, pak zkontrolujte čísla, pak otestujte věci, které uživatelé skutečně dělají. Doktor odhalí problémy na úrovni databáze; ruční kontroly odhalí problémy se ztrátou dat a přístupem, které doktor vidět nemůže.

1. Spusťte forgejo doctor check --all --log-file /tmp/doctor.log, pak si před provedením změn přečtěte log. Použijte --fix pouze pro konkrétní opravu, které rozumíte.
2. Ověřte, že počet repozitářů, počet issues a PR i počet objektů LFS a jejich celková velikost odpovídají číslům před migrací. Pokud se něco neshoduje, znamená to, že se něco nepřeneslo.
3. Otestujte push a pull přes SSH. Pokud klienti dostanou chybu neshody host key, nezkopírovali jste /etc/ssh/ssh_host_* na nový server.
4. Přihlaste se a ověřte, že 2FA funguje u účtu, který ji používá. Pokud je TOTP rozbité, viz upozornění u možnosti A výše.
5. Znovu vygenerujte osobní přístupové tokeny, znovu zaregistrujte runnery pro Actions a spusťte testovací workflow.

Několik příznaků po migraci má známé příčiny. Chybějící favicon nebo logo znamená, že vaše brandingové soubory jsou stále v public/assets/img/ místo v custom/, kde je Forgejo nyní očekává. Chyby 404 na cestách balíčků ukazují na špatně nastavené cesty úložiště. Selhání Actions s hláškou "repository not found" je uses: problém se zrcadlem. Přepněte na plné URL adresy. Prázdná stránka nebo chyba 500 po přihlášení u databáze SQLite znamená, že jste pod minimem, což dokumentace k upgradu stanoveno na Forgejo v1.19.3-0.

Kdy dává smysl zůstat u Gitea

Migrace je volba, ne povinnost. Pokud jste už za touto hranicí a složitost migrace ve vaší situaci převažuje nad přínosem v řízení projektu nebo funkcích, zůstat na Gitea je legitimní volba. Gitea je aktivně udržovaná (několik releasů měsíčně, aktuálně u v1.26.4) a CommitGo nabízí komerční možnosti včetně Gitea Enterprise, Gitea Cloud a certifikaci SOC 2 Type 2 pro týmy, které je potřebují.

Je také třeba poctivě zvážit obavu z mezikroku po EOL. Podporovaná přímá cesta vyžaduje krátkodobou instalaci Forgejo v10.0, která má EOL od dubna 2025. To je přijatelné jako dočasný migrační krok, od kterého ihned upgradujete dál, ale někteří provozovatelé proti tomu budou mít výhrady z principu. Pro ně se migrace přes repozitář/API do nové instance Forgejo může EOL mezikroku zcela vyhnout, zatímco příprava na novém serveru stále závisí na zvolené migrační metodě.

Pokud je vaším důvodem pro přechod vývojová aktivita, data podporují Forgejo jako aktivnější projekt: analýza od honeypot.net napočítal 3 039 commitů Forgejo oproti 1 228 commitům Gitea za období od července 2024 do května 2025 a 232 přispěvatelů Forgejo oproti 153 u Gitea za rok končící květnem 2025. To je jeden signál mezi několika; zvažte ho proti riziku migrace, spíše než ho brát jako rozhodující.

Shrnutí sekce: migrace není povinná. Rozhodnutí je otázkou preference správy a aktivity zvážené proti riziku migrace, a obě volby jsou obhajitelné.

Vyberte si cestu a nejprve zálohujte

Vaše migrační cesta se scvrkává na jedno číslo: vaši verzi Gitea. U v1.22 nebo starší jdete podporovanou dvoukrokovou cestou přes Forgejo v10. U v1.23 nebo novější si vyberete náhradní řešení podle míry ztráty dat, se kterou se dokážete smířit: downgrade SQL/schématu, komunitní skripty, migraci přes repozitář/API nebo přípravu na novém serveru. Ať zvolíte jakoukoli cestu, nejprve zálohujte svůj datový adresář a databázi, spusťte forgejo doctor poté a ověřte, že počty repozitářů, issues a LFS souhlasí s tím, s čím jste začínali.

Určete svou verzi, vytvořte zálohu a postupujte podle odpovídajícího řádku. Cesta je náročnější, než sliboval starý návod, ale jakmile víte, kde přesně na verzní hranici stojíte, je jasně daná.

Časté dotazy

Mohu upgradovat přímo z Gitea na Forgejo?

Ano, pokud provozujete Gitea v1.22 nebo starší: upgradujte přímo na Forgejo v10.0 a poté Forgejo v10 na aktuální release. Ne, pokud provozujete Gitea v1.23 nebo novější. Forgejo v10.0 byl poslední release podporující transparentní přímý upgrade, takže novější verze Gitea místo toho potřebují náhradní řešení.

Která verze Gitea je kompatibilní s Forgejo?

Gitea v1.22 a starší mají podporovanou přímou cestu upgradu na Forgejo (až do Forgejo v10.0, poté dál na aktuální verzi). Gitea v1.23 a novější nemají žádnou oficiálně podporovanou přímou cestu, protože Forgejo přestalo podporovat transparentní upgrady z Gitea v1.23+ v releasech po v10.0.

Mohu migrovat z Gitea 1.26 do Forgejo?

Ano, ale ne přes podporovaný přímý upgrade. Vaše možnosti jsou migrace přes repozitář/API, kde je historie git spolehlivá část a metadata je nutné testovat repozitář po repozitáři, experimentální migrační skript, nebo příprava na novém serveru pomocí některé z výše uvedených nepodporovaných metod pro 1.23+. Z Gitea 1.26 neexistuje oficiálně podporovaná cesta na místě.

Přenesou se mé Personal Access Tokens?

Po migraci počítejte s tím, že budete muset osobní přístupové tokeny znovu vytvořit nebo obměnit. Některé migrační cesty je nezachovávají, a i když tokeny zůstanou zachovány, uživatelé by měli před dalším spoléháním na ně zkontrolovat jejich oprávnění. Veškeré skripty nebo integrace používající staré tokeny by měly být po přechodu otestovány a aktualizovány.

Fungují moje workflow Gitea Actions ve Forgejo?

Většinou ano, se dvěma nutnými úpravami. Workflow uses: krátké odkazy se rozbijí, protože Forgejo a Gitea stahují akce ze samostatných zrcadel. Přepněte je na plné URL adresy GitHub (například uses: https://github.com/sammcj/dotenv-output-action@main). Musíte také znovu zaregistrovat své Actions runnery, protože jejich registrační tokeny jsou vázané na starý hostname.

Co migrace z Gogs na Forgejo?

To je jiná migrace s jinou cestou a je mimo rozsah tohoto článku. Tento návod se týká konkrétně přechodu z Gitea na Forgejo; pro zdroj Gogs nahlédněte do oficiální migrační dokumentace Forgejo, kde najdete postup specifický pro Gogs.