Hogyan migrálj Gitea-ból Forgejo-ba a repóid tönkretétele nélkül

Leállítod a Gitea-t, telepíted a Forgejo-t, átmásolod az app.ini fájlt és az adatkönyvtáradat, majd elindítod a szolgáltatást úgy, ahogy minden migrációs útmutató leírja. A webes UI elindul. Aztán az adatbázis migráció meghiúsul, vagy ami rosszabb, a Forgejo nem hajlandó elindulni, mert a séma verziója túl új ahhoz, hogy megértse. Gitea 1.23-at vagy újabbat futtatsz, és a mindenki által dokumentált egyszerű helyben történő frissítés már nem vonatkozik rád.

A Forgejo 2024 elején vált a Gitea kemény forkjává, és azóta a két projekt adatbázis-séma szinten is elvált egymástól. Hogy hogyan migrálod a Gitea-t Forgejo-ra, ma már teljes mértékben a Gitea verziódtól függ. Ez az útmutató pontos utat ad a te verziódhoz, teljes parancssort mind a natív, mind a Docker telepítésekhez, megoldásokat a Gitea 1.23+ esetére, valamint egy ellenőrzőlistát, hogy repók, issue-k és felhasználók elvesztése nélkül migrálhass.

Röviden

• A verziószakadék valós. A Forgejo v10.0 volt az utolsó kiadás, amely támogatta az átlátható közvetlen frissítést a Gitea-ból. A Gitea v1.22 a legmagasabb verzió, amely a támogatott közvetlen utat választhatja.
• Gitea v1.22 vagy korábbi esetén: migrálj először Forgejo v10.0.x-re, majd frissítsd a Forgejo v10-et az aktuális kiadásra (v15). Két lépés, mindkettő támogatott.
• Gitea v1.23 vagy újabb esetén: nincs hivatalosan támogatott közvetlen út. Választhatsz SQL/séma visszaállítás, közösségi migrációs szkriptek, repo/API migráció, vagy egy friss szerveres staging migráció közül ezen módszerek egyikének felhasználásával. Mindegyik más-más adatvesztési kompromisszummal jár.
• Készíts biztonsági mentést az adatkönyvtáradról és az adatbázisodról, mielőtt bármihez is hozzányúlnál. Az alábbi utak mindegyike feltételezi, hogy van visszaállítható mentésed. A nem támogatott utak ezt duplán is megkövetelik.
• Bizonyos dolgok mindig figyelmet igényelnek a migráció után: tervezd meg a Personal Access Tokenek újralétrehozását vagy ellenőrzését, az Actions futtatók újraregisztrálását, valamint a Bleve keresőindex törlését és újraépítését. Ezekre az úttól függetlenül számíts.
• A migráció nem kötelező. A Gitea aktívan karbantartott. A „maradok a Giteánál” döntés akkor helytálló, ha a migrációs kockázat meghaladja a hasznot a te helyzetedben.

Nem témája ennek a cikknek: a Gogs, GitHub vagy GitLab rendszerről Forgejo-ra való migrálás, valamint a Forgejo Actions nulláról történő beállítása.

Előfeltételek / Amire szükséged lesz

Mielőtt egyetlen parancsot is kiadnál, győződj meg róla, hogy két dologról teljes, visszaállítható biztonsági mentésed van: a Gitea adatkönyvtáráról (alapértelmezett natív telepítés esetén /var/lib/gitea) és az adatbázisodról. Ha az adatbázisod SQLite, az a fájl az adatkönyvtáron belül található; ha PostgreSQL vagy MySQL, mentsd külön a pg_dump vagy a mysqldump segítségével. Egy ellenőrzött mentés nélküli migráció nem migráció, hanem szerencsejáték.

Ezenkívül szükséged lesz még:

• A jelenlegi Gitea verziód. Futtasd le gitea --version (vagy docker exec <container> gitea --version). Ez a szám dönti el a teljes utat, amit követned kell.
• Az adatbázis típusod: SQLite, PostgreSQL vagy MySQL. Egyes megoldások adatbázis-specifikusak.
• Root vagy sudo hozzáférés a szerveren.
• Tudatában kell lenned annak, hogy a támogatott út a Forgejo v10.0-t telepíti köztes lépésként. A Forgejo v10.0 2025. április 16. óta EOL állapotú. Csak a migráció idejére telepíted, majd azonnal frissítesz róla.

Miért tört meg a közvetlen frissítési út

2024 decemberében a Forgejo projekt közzétett egy kompatibilitási nyilatkozat amely éles határvonalat húzott: "A jövőbeli Forgejo verziók nem fogják támogatni a v1.23 vagy afeletti verziót futtató Gitea példányokból történő frissítést." Ez a mondat foglalja össze az egész problémát egyetlen sorban.

Amikor a Forgejo 2024 elején leágazott a Gitea-ból, a két kódbázis egyre inkább eltávolodott egymástól, és az adatbázis sémák is szétváltak. A Forgejo fenntartott egy kompatibilitási ablakot, hogy a meglévő Gitea üzemeltetők átválthassanak, de ennek az ablaknak vége szakadt. A 2025. január 16-án megjelent Forgejo v10.0 volt "the last version to allow a transparent upgrade from Gitea v1.22 or lower." A v10.0-nál újabb verziók egyike sem tudja közvetlenül beolvasni a Gitea adatbázisát.

Az időzítés az, ami sokakat meglep. A Gitea v1.23 verziója 2024 végén jelent meg, és a a jelenlegi Gitea kiadás 2026 júniusától v1.26.4. Ha a Gitea-példányodat viszonylag naprakészen tartottad, akkor már túl vagy a határon, és a szokásos oktatóanyagok már nem írják le a helyzetedet.

A szakasz lényege: a támogatott közvetlen út a Gitea v1.22 verziónál ér véget. Minden újabb verzió extra lépést igényel.

Találd meg a migrációs utadat a Gitea verziója alapján

Futtasd le gitea --version, keresd meg a saját sorodat, és kövesd a harmadik oszlopban megadott utat. Az útmutató többi része ezeknek a soroknak a részleteit tartalmazza.

A verziókompatibilitási nyilatkozatok közvetlenül innen származnak: hivatalos Forgejo kompatibilitási bejelentés: a Gitea v1.21-ig bezárólag Forgejo v7.0-tól v10.0-ig migrálható, a Gitea v1.22 pedig Forgejo v8.0-tól v10.0-ig. Mindkettő esetében a v10.0 a legmagasabb támogatott közvetlen célverzió.

A verziókérdés mögött három migrációs stratégia húzódik meg, és hasznos ezeket látni a lépésenkénti útmutatók előtt:

• Helyben, ugyanazon a szerveren. Cseréld le a binárist vagy a konténerképet a meglévő gépen. Ez a legkisebb erőfeszítést igénylő megoldás, ha a verziód támogatja; a v10.0 közbenső lépés szükséges hozzá.
• Friss szerveres előkészítés. Hozz létre egy új szervert, és használd biztonságos célpontként a Gitea verziódnak megfelelő migrációs módszerhez. Ez megvédi az eredeti Gitea gépet, és megkönnyíti a visszaállítást, de nem kerüli meg a Gitea 1.23+ adatbázis-séma problémáját.
• Repo/API migráció. Használd a Forgejo migrációs eszközeit a repository-k lehívásához a régi Gitea-példányból. A git előzmények a megbízható rész; az olyan metaadatokat, mint az issue-k, PR-ek, címkék, kiadások, wiki adatok és hozzászólások, legjobb erőfeszítésként kell kezelni, és repónként ellenőrizni.

A támogatott út: Gitea v1.22 vagy korábbi

Ha Gitea v1.22-n vagy korábbin vagy, a hivatalos migrációs dokumentáció egy két lépéses utat írnak le: migrálj Forgejo v10.0.x-re, majd frissítsd a Forgejo v10-et az aktuális kiadásra. Az első lépés közvetlen csere, mivel a Forgejo v10.x beolvassa a Gitea v1.22 adatbázisát; a második lépés egy normál Forgejo frissítés.

Ennek két módja van attól függően, hogy a Gitea hogyan fut a szervereden. Válaszd azt, amelyik illik a meglévő beállításodhoz. Ha a Gitea rendszerszolgáltatásként fut, használd a natív utat. Ha a Gitea konténerben fut, használd a Docker utat. A Forgejo v10.x közvetlen helyettesítőként működik a Gitea v1.22.x helyett.

Natív (systemd) útvonal

Először készíts biztonsági mentést. Ezután telepítsd a Forgejo v10.0.x verzióját a disztribúciód csomagjával vagy a v10.0-hoz rögzített kiadási binárissal. Állítsd le a Gitea-t, mielőtt bármit is másolnál. Egy futó szolgáltatás, amely másolás közben ír az adatkönyvtárába, tönkreteszi a másolatot.

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

Másold a konfigurációt és az adatkönyvtárat a Forgejo megfelelő helyeire, majd javítsd ki a tulajdonjogokat. A konfigurációs fájlnak csoportszinten olvashatónak kell lennie a forgejo csoport számára; az adatok tulajdonosának a forgejo felhasználónak kell lennie.

# 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

Indítsd el a Forgejo-t, és engedélyezd az induláskori indítást.

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

Mielőtt frissítenél a v10.0-ról, ürítsd ki a várólistákat, hogy a verzióváltás során ne vesszen el folyamatban lévő munka.

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

Most frissítsd a Forgejo v10.0.x verziót az aktuális kiadásra úgy, hogy a binárist v15-re cseréled, és újraindítod a szolgáltatást, követve a szokásos Forgejo frissítési útmutató. Mindkét lépés után futtasd a doctor parancsot, hogy ellenőrizze az adatbázist, és kijavítsa, amit tud.

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

Olvasd el /tmp/doctor.log mielőtt bármilyen automatikus javítást alkalmaznál. Használd --fix csak akkor, amikor a doctor kimenete egy konkrét, általad megértett javítást azonosít, vagy amikor egy hivatalos hibaelhárítási utat követsz.

Ha a doctor nem jelent kritikus hibát, és a webes felület listázza a repóidat, az első migráció kész.

Docker / konténer útvonal

Ha a Gitea konténerként futott, futtasd ugyanígy a Forgejo-t is. Használd a Forgejo v10.x image-et közvetlen helyettesítőként a Gitea v1.22.x image-ed helyett, ugyanarra az adatkötetre és adatbázisra mutatva. Előbb ellenőrizd, hogy a Docker verziód legalább 20.10.6-e. A régebbi verziók nem meghatározott viselkedést produkálnak a Forgejo konténerekkel.

Az egyetlen konténer-specifikus részlet, ami sokakat megzavar: a környezeti változók. A Forgejo a kompatibilitás érdekében megtartja a GITEA_ előtagot, de a dokumentáció azt javasolja, hogy mindkét előtagot add meg, hogy a konfigurációd túléljen egy jövőbeli Forgejo verziót, amely elhagyja a régi neveket.

# 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

Rootless konténerek esetén az adatoknak az 1000-es felhasználó és az 1000-es csoport tulajdonában kell lenniük, megfelelve a rootless image futásidejű felhasználójának. Miután a konténer elindult a v10.x verzión, futtasd ugyanazt a forgejo doctor check --all a konténeren belülről, majd frissítsd az image taget az aktuális v15 kiadásra, és indítsd újra.

Ha Gitea v1.23-on vagy újabbon vagy

Itt érnek véget a szokásos útmutatók, és itt tart a legtöbb jelenlegi telepítés valójában. Nincs hivatalosan támogatott közvetlen út a Gitea v1.23+ verzióról, így az alábbi lehetőségek mindegyike vagy közösségi eredetű, vagy adatvesztéssel jár. Mielőtt bármelyiket futtatnád, készíts teljes biztonsági mentést az adatkönyvtáradról és az adatbázisodról, és győződj meg róla, hogy vissza tudod állítani. Ezek a megközelítések módosítják az éles adatokat; a mentés az egyetlen visszavonási lehetőséged.

A három lehetőség eltér a kockázatban és abban, hogy mennyit őriznek meg. Válaszd azt, amelynek kompromisszumát el tudod fogadni.

A opció: SQL séma visszaállítás / verziófolt

A legszűkebb megoldás visszaállítja az adatbázis séma verzióját, hogy a Forgejo v10 v1.22-es adatbázisként kezelje.

Megjegyzés: ne kezeld a verziófrissítést önmagában teljes visszafejlesztésként. A rögzített migrációs verziónak és a tényleges sémának egyeznie kell. Gitea 1.23.x esetén először egy másolaton teszteld a teljes visszafejlesztést, és hasonlítsd össze a sémát, mielőtt a Forgejo-t ráirányítanád.

Egy Forgejo karbantartó a SQL-t a Codeberg issue #7638:

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

Ezután a támogatott utat követed, mintha v1.22-n lennél. A kritikus figyelmeztetés: a karbantartó ezt kifejezetten csak a Gitea v1.23.1-re erősítette meg, nem az egész v1.23.x sorozatra. A séma verziószáma pontos érték; ha rossz célértéket alkalmazol a rossz Gitea kiadásra, az adatbázis olyan állapotba kerülhet, amelyből semmilyen migráció nem tudja helyreállítani. Ez PostgreSQL/MySQL esetén érvényes, nem hivatalosan támogatott, és nincs általános eljárásként tesztelve.

Szakértői tipp: a version=305 érték közvetlen beállítása kihagyja a 304→305 migrációt, amely megváltoztatta a TOTP titkok kódolásának módját. Codeberg issue #8210 dokumentálja, hogy ez tönkreteszi az érintett felhasználók kéttényezős hitelesítését. A megoldás a verzió 304-re állítása, a migráció lefuttatása, vagy a two_factor tábla sorainak törlése, hogy a felhasználók újra regisztrálhassák magukat. Ezt ne hagyd ki, ha bármelyik fiók TOTP-t használ.

B opció: szekvenciális SQL visszaállító szkriptek (Gitea 1.24–1.25.2)

Az 1.24 és 1.25.2 közötti verziók esetén egyetlen verziófolt nem elég: a séma több köztes állapoton is átment. A közösségi scriptek a xlrl/prepare-gitea-migration-to-forgejo visszaviszik a sémát a közbenső verziókon keresztül v1.22-re, ami után a támogatott utat követed. Ezek a szkriptek közösségi munkák, nem hivatalos eljárás, és elsődlegesen az SQLite esetére készültek. Csak olyan adatbázison futtasd le őket, amelyről már készítettél biztonsági mentést.

C opció: repónkénti API migráció (Gitea 1.26+ vagy bármely verzió)

A repo/API út őrzi meg a legmegbízhatóbban a git adatokat. A forrástól, a jogosultságoktól és a migrációs módszertől függően olyan opcionális metaadatok is elérhetők lehetnek, mint az issue-k, pull request-ek, címkék, mérföldkövek, kiadások, wiki adatok és hozzászólások, de ezeket kezeld legjobb erőfeszítésként, és ellenőrizd repónként. Egy csak kódot tartalmazó archívumhoz ez általában megfelelő; ha az issue tracker a csapat memóriája, teszteld a metaadatok átvitelét, mielőtt elköteleződnél emellett az út mellett.

Két kísérleti eszköz próbál teljesebb migrációt végezni az 1.23+ verziókhoz, de mindkettőnek megvannak a saját hiányosságai. pacnpal/gitea2forgejo (GitHub) teljes dumpot végez API-szinkronizálással, és a titkosított mezők átviteléhez egyező SECRET_KEY-re van szükség, viszont nem viszi át a Personal Access Tokeneket, az Actions runnereket, a webhook callback URL-eket vagy a 2FA-t. nicoverbruggen/gitea-to-forgejo (GitHub) egy Podman-alapú, kísérleti eszköz, amely átviszi a felhasználókat, kulcsokat, szervezeteket, repókat, issue-kat, PR-eket, kiadásokat és mirrorokat, de nem viszi át a 2FA tokeneket, az Actions futásidejű adatait, sem a gazdátlan OCI csomag-manifeszteket. Mindkettőt kísérletinek kell tekinteni, az eredményt pedig az alábbi átviteli mátrix alapján kell ellenőrizni.

A szakasz lényege: nincs hivatalosan támogatott közvetlen út a Gitea 1.23+ verzióról. Válaszd azt a lehetőséget, amelynek adatvesztési kompromisszumával együtt tudsz élni, és kezdés előtt készíts biztonsági mentést.

A friss szerveren végzett migráció biztonságosabb, de nem kerüli meg a verziós határvonalat

Egy friss szerver a legbiztonságosabb hely a migráció előkészítésére és ellenőrzésére, de ez nem egy külön séma-kompatibilitási út. Ha a forrásod Gitea v1.22 vagy korábbi, először telepítsd a Forgejo v10.0.x verzióját a célgépre, állítsd vissza vagy másold oda a Gitea adatait, hagyd, hogy a Forgejo lefuttassa a támogatott adatbázis-migrációkat, majd frissítsd fel ezt a Forgejo v10 példányt az aktuális Forgejo kiadásra.

Ha a forrásod Gitea v1.23 vagy újabb, ne állítsd vissza közvetlenül a Gitea adatbázisát az aktuális Forgejo-ba, abban a reményben, hogy elindul. Továbbra is szükséged van a fent felsorolt, nem támogatott 1.23+ megközelítések egyikére: egy fokozatos SQL-visszafejlesztésre vagy visszaállításra, egy közösségi migrációs eszközre, vagy egy repó/API-migrációra. A friss szerver csökkenti a visszaállítási kockázatot, mivel az eredeti Gitea gép érintetlen marad; de nem szünteti meg az adatbázis-verzió eltérésének kezelésére való szükséget.

Ez az a pont, ahol A Cloudzy egykattintásos Forgejo alkalmazás segíthet: használd tiszta célpéldányként, majd futtasd le a Gitea verziódnak megfelelő migrációs módszert. A Cloudzy marketplace image-e kész Forgejo célpontot ad a mi nagy teljesítményű VPS, így a visszaállításra, az ellenőrzésre és az átállási lépésekre koncentrálhatsz a kezdeti telepítés helyett. A migrációs terv továbbra is attól függ, hogy a Gitea 1.22-es határ előtt vagy után jársz-e.

Mi kerül át, és mit kell újra elvégezned

Az adataid egy része automatikusan átkerül, egy része csak akkor, ha egy feltétel teljesül, egy része pedig soha nem kerül át, és kézzel kell újralétrehozni. Ha kezdés előtt tudod, melyik melyik, az a különbség egy tiszta átállás és egy hét zavart felhasználó között.

Négy dolog okozza a legtöbb fájdalmat, mert csendben törnek el, vagy minden felhasználót érintenek, ezért ezekkel tudatosan kell foglalkozni: a felhasználóknak újra kell létrehozniuk vagy át kell tekinteniük a Personal Access Tokenjeiket, újra kell regisztrálnod az Actions runnereket az új hosztnévhez, törölnöd kell a Bleve keresési indexet, hogy a Forgejo tisztán újraépítse, és át kell írnod minden uses: a rövid hivatkozásokat az Actions workflow-jaidban teljes GitHub URL-ekre, mert a Forgejo és a Gitea külön tükrökből húzzák le az actionöket, és egy relatív hivatkozás rossz helyre mutat.

Szakértői tipp: ha a migráció alatt párhuzamosan futtatod a Gitea-t és a Forgejo-t, és mindkettő ugyanarra a Redis-példányra mutat, állítsd át a Forgejo-t a Redis db=1 adatbázisra, mielőtt elkezded. Alapértelmezés szerint mindkettő a db=0-t használja, és ha megosztják, a Gitea felemészti a Forgejo migrációs eseményeit, és tönkreteszi a migrációs sort. (blog.mei-home.net documents this exact failure.)

A szakasz lényege: a Personal Access Tokenek, az Actions futtatók, a repónkénti telepítési kulcsok és a Bleve keresőindex mindig kézi feladatok. Ütemezd be ezeket migrációs feladatként, ne utólagos ötletként.

Ellenőrizd, hogy a migráció sikeres volt-e

Kezdd a doctor eszközzel, majd ellenőrizd a számokat, végül teszteld azokat a dolgokat, amiket a felhasználók ténylegesen csinálnak. A doctor az adatbázis szintű problémákat kapja el; a kézi ellenőrzések azokat az adatvesztési és hozzáférési problémákat fogják meg, amelyeket a doctor nem lát.

1. Futtasd le forgejo doctor check --all --log-file /tmp/doctor.log, majd a módosítások elvégzése előtt olvasd el a naplót. Használd a --fix csak egy konkrét, általad megértett javításhoz.
2. Ellenőrizd, hogy a repók száma, az issue-k és PR-ek száma, valamint az LFS objektumok száma és teljes mérete megegyezik-e a migráció előtti számokkal. Ha itt eltérést találsz, az azt jelenti, hogy valami nem került át.
3. Teszteld az SSH push-t és pull-t. Ha a kliensek host-kulcs eltérést kapnak, akkor nem másoltad át a /etc/ssh/ssh_host_* fájlokat az új szerverre.
4. Jelentkezz be, és ellenőrizd, hogy a 2FA működik-e egy olyan fiókon, amely használja. Ha a TOTP nem működik, lásd a fenti A opcióhoz tartozó figyelmeztetést.
5. Generáld újra a Personal Access Tokeneket, regisztráld újra az Actions futtatókat, és futtass le egy teszt workflow-t.

Néhány migráció utáni tünetnek ismert oka van. A hiányzó favicon vagy logó azt jelenti, hogy a márkajelzési fájlok még mindig a public/assets/img/ mappában vannak a custom/ helyett, ahol a Forgejo most már várja őket. A csomag-útvonalakon jelentkező 404-es hibák hibásan konfigurált tárolási útvonalakra utalnak. A „repository not found” hibával leálló Actions a uses: tükör probléma. Válts teljes URL-ekre. Egy üres vagy 500-as oldal bejelentkezés után SQLite adatbázison azt jelenti, hogy a minimum alatt vagy, amit a frissítési dokumentáció Forgejo v1.19.3-0-nál húzta meg.

Mikor van értelme a Gitea-n maradni

A migráció választás, nem kötelezettség. Ha már túl vagy a határvonalon, és a migráció bonyolultsága meghaladja az irányítási vagy funkcionális előnyt a te helyzetedben, a Gitea-nál maradás jogos választás. A Gitea aktívan karbantartott (havonta több kiadással, jelenleg v1.26.4-nél tart), és a CommitGo kereskedelmi lehetőségeket is kínál, beleértve a Gitea Enterprise, Gitea Cloud, valamint SOC 2 Type 2 tanúsítvány azoknak a csapatoknak, akiknek szükségük van rájuk.

Van egy másik, EOL-közbenső aggály is, amit érdemes őszintén mérlegelni. A támogatott közvetlen út megköveteli a Forgejo v10.0 rövid ideig tartó telepítését, amely 2025 áprilisa óta EOL állapotban van. Ez elfogadható átmeneti migrációs lépésként, amelyről azonnal továbblépsz, de egyes üzemeltetők elvi okokból ellenezni fogják. Számukra a repo/API migráció egy friss Forgejo-példányba teljesen elkerülheti az EOL lépést, míg a friss szerveres staging még mindig az általad választott migrációs módszertől függ.

Ha a váltás oka a fejlesztési aktivitás, az adatok a Forgejo-t támasztják alá aktívabb projektként: egy elemzés a honeypot.net 3039 Forgejo commitot számolt 1228 Gitea commit ellenében 2024 júliusa és 2025 májusa között, valamint 232 Forgejo közreműködőt 153 Gitea közreműködő ellenében a 2025 májusáig tartó év során. Ez csak egy jelzés a több közül; mérlegeld a migrációs kockázatoddal szemben, ahelyett hogy döntőnek tekintenéd.

A szakasz lényege: a migráció nem kötelező. A döntés a kormányzási és aktivitási preferenciák és a migrációs kockázat mérlegelése, és mindkét választás védhető.

Válaszd ki az utad, és először készíts biztonsági mentést

A migrációs utad egyetlen számon múlik: a Gitea verziódon. A v1.22 vagy korábbi esetén a támogatott, két lépéses utat választod a Forgejo v10-en keresztül. A v1.23 vagy újabb esetén az elfogadható adatvesztés alapján választasz megoldást: SQL/séma visszaállítás, közösségi szkriptek, repo/API migráció, vagy friss szerveres staging migráció. Bármelyik utat is választod, először mentsd el az adatkönyvtáradat és az adatbázisodat, majd futtasd le forgejo doctor utána, és győződj meg róla, hogy a repository, issue és LFS számok megegyeznek azzal, amivel kezdted.

Azonosítsd a verziódat, készíts mentést, és kövesd a megfelelő sort. Az út bonyolultabb, mint amit a régi oktatóanyagok ígértek, de jól meghatározott, ha egyszer tudod, hol állsz a verziós határvonalon.

Gyakran ismételt kérdések

Frissíthetek közvetlenül Gitea-ról Forgejo-ra?

Igen, ha Gitea v1.22 vagy korábbi verziót futtatsz: frissíts közvetlenül Forgejo v10.0-ra, majd frissítsd a Forgejo v10-et az aktuális kiadásra. Nem, ha Gitea v1.23-at vagy újabbat futtatsz. A Forgejo v10.0 volt az utolsó kiadás, amely átlátható közvetlen frissítést támogatott, így az újabb Gitea verziókhoz megoldás szükséges helyette.

Melyik Gitea verzió kompatibilis a Forgejo-val?

A Gitea v1.22 és korábbi verziók esetén létezik támogatott, közvetlen frissítési út a Forgejo felé (a Forgejo v10.0-ig, majd onnan tovább az aktuális verzióig). A Gitea v1.23 és újabb verziók esetén nincs hivatalosan támogatott közvetlen út, mivel a Forgejo a v10.0 utáni kiadásoktól kezdve megszüntette az átlátható frissítések támogatását a Gitea v1.23+ verzióiról.

Migrálhatok Gitea 1.26-ról Forgejo-ra?

Igen, de nem támogatott közvetlen frissítéssel. A lehetőségeid: egy repo/API migráció, ahol a git előzmények a megbízható rész, a metaadatokat pedig repónként kell tesztelni, egy kísérleti migrációs szkript, vagy egy friss szerveres staging migráció a fent említett, nem támogatott 1.23+ módszerek egyikével. Nincs hivatalosan támogatott helyben történő út a Gitea 1.26 verzióról.

Átkerülnek a Personal Access Tokenjeim?

Tervezd meg a Personal Access Tokenek újralétrehozását vagy cseréjét a migráció után. Egyes migrációs utak nem őrzik meg ezeket, és még ha a tokenek megmaradnak is, a felhasználóknak ellenőrizniük kell a jogosultsági köröket, mielőtt újra rájuk hagyatkoznának. A régi tokeneket használó szkripteket és integrációkat az átállás után tesztelni és frissíteni kell.

Működnek a Gitea Actions workflow-jaim a Forgejo-ban?

Nagyrészt igen, két kötelező javítással. A workflow uses: a rövid hivatkozások megszakadnak, mert a Forgejo és a Gitea külön tükrökből húzzák le az actionöket. Válts teljes GitHub URL-ekre (például uses: https://github.com/sammcj/dotenv-output-action@main). Az Actions runnereket is újra kell regisztrálnod, mivel a regisztrációs tokenjeik a régi hosztnévhez vannak kötve.

Mi a helyzet a Gogs-ról Forgejo-ra való migrálással?

Ez egy másik migráció, más úttal, és nem témája ennek a cikknek. Ez az útmutató kifejezetten a Gitea-ról Forgejo-ra való migrációt tárgyalja; ha Gogs a forrás, nézd meg a Forgejo hivatalos migrációs dokumentációját a Gogs-specifikus eljárásért.