Cara Migrasi dari Gitea ke Forgejo Tanpa Merusak Repositories Anda

Anda menghentikan Gitea, menginstal Forgejo, menyalin app.ini dan direktori data Anda, lalu menjalankan service seperti yang dijelaskan setiap panduan migrasi. Web UI muncul. Kemudian migrasi database gagal, atau lebih buruk lagi, Forgejo menolak untuk start karena versi skema Anda terlalu baru untuk dipahaminya. Anda berada di Gitea 1.23 atau lebih baru, dan upgrade in-place sederhana yang didokumentasikan semua orang sudah tidak berlaku lagi untuk Anda.

Forgejo menjadi hard fork dari Gitea pada awal 2024, dan sejak itu kedua proyek tersebut berbeda pada tingkat skema database. Bagaimana Anda memigrasikan Gitea ke Forgejo sekarang sepenuhnya bergantung pada versi Gitea Anda. Panduan ini memberikan jalur yang tepat untuk versi Anda, perintah lengkap untuk instalasi native maupun Docker, solusi untuk Gitea 1.23+, dan checklist verifikasi, sehingga Anda dapat bermigrasi tanpa kehilangan repositories, issues, atau users.

TL;DR

• Jurang versi ini nyata. Forgejo v10.0 adalah rilis terakhir yang mendukung upgrade langsung secara transparan dari Gitea. Gitea v1.22 adalah versi tertinggi yang dapat menempuh jalur langsung yang didukung.
• Pada Gitea v1.22 atau lebih lama: migrasi ke Forgejo v10.0.x terlebih dahulu, lalu upgrade Forgejo v10 ke rilis terkini (v15). Dua langkah, keduanya didukung.
• Pada Gitea v1.23 atau lebih baru: tidak ada jalur langsung yang didukung secara resmi. Anda memilih antara downgrade SQL/skema, skrip migrasi komunitas, migrasi repo/API, atau migrasi staging server baru menggunakan salah satu metode tersebut. Masing-masing memiliki trade-off kehilangan data yang berbeda.
• Buat backup direktori data dan database Anda sebelum menyentuh apa pun. Setiap jalur di bawah ini mengasumsikan Anda memiliki backup yang dapat dipulihkan. Jalur yang tidak didukung mengasumsikannya dua kali lipat.
• Beberapa hal selalu memerlukan perhatian pasca migrasi: rencanakan untuk membuat ulang atau mengaudit Personal Access Tokens, mendaftarkan ulang runner Actions, serta menghapus dan membangun ulang indeks pencarian Bleve. Rencanakan hal-hal ini apa pun jalur yang Anda ambil.
• Migrasi bukanlah suatu keharusan. Gitea dikelola secara aktif. Keputusan "tetap di Gitea" tetap masuk akal jika risiko migrasi lebih besar daripada manfaatnya untuk situasi Anda.

Di luar cakupan panduan ini: migrasi dari Gogs, GitHub, atau GitLab ke Forgejo, serta penyiapan Forgejo Actions dari nol.

Prasyarat / Yang Anda Perlukan

Sebelum menjalankan satu perintah pun, pastikan Anda memiliki backup lengkap dan dapat dipulihkan dari dua hal: direktori data Gitea Anda (/var/lib/gitea pada instalasi native default) dan database Anda. Jika database Anda adalah SQLite, file tersebut berada di dalam direktori data; jika PostgreSQL atau MySQL, dump secara terpisah dengan pg_dump atau mysqldump. Migrasi tanpa backup yang terverifikasi bukanlah migrasi, melainkan sebuah pertaruhan.

Anda juga akan memerlukan:

• Versi Gitea Anda saat ini. Jalankan gitea --version (atau docker exec <container> gitea --version). Angka ini menentukan seluruh jalur migrasi Anda.
• Jenis database Anda: SQLite, PostgreSQL, atau MySQL. Beberapa workaround bersifat khusus untuk database tertentu.
• Akses root atau sudo pada server.
• Kesadaran bahwa jalur yang didukung menginstal Forgejo v10.0 sebagai titik singgah perantara. Forgejo v10.0 sudah EOL sejak 16 April 2025. Anda hanya menginstalnya selama proses migrasi berlangsung dan segera melakukan upgrade meninggalkannya.

Mengapa Jalur Upgrade Langsung Rusak

Pada Desember 2024, proyek Forgejo mempublikasikan sebuah pernyataan kompatibilitas yang menarik garis tegas: "Future Forgejo versions will not support upgrades from Gitea instances running version v1.23 or above." Kalimat itu adalah keseluruhan masalahnya dalam satu baris.

Ketika Forgejo di-fork dari Gitea pada awal 2024, kedua codebase terus berkembang secara terpisah, dan skema database-nya pun makin berbeda. Forgejo mempertahankan jendela kompatibilitas agar operator Gitea yang sudah ada bisa berpindah, tetapi jendela itu memiliki batas akhir. Forgejo v10.0, dirilis pada 16 Januari 2025, adalah "the last version to allow a transparent upgrade from Gitea v1.22 or lower." Versi apa pun yang lebih baru dari v10.0 tidak akan dapat membaca database Gitea secara langsung.

Yang membuat orang terkejut adalah waktunya. Gitea v1.23 dirilis pada akhir 2024, dan rilis Gitea terkini per Juni 2026 adalah v1.26.4. Jika Anda menjaga instance Gitea Anda tetap cukup mutakhir, Anda sudah melewati titik kritis tersebut dan tutorial standar tidak lagi menggambarkan situasi Anda.

Inti bagian ini: jalur langsung yang didukung hanya berlaku hingga Gitea v1.22. Semua versi yang lebih baru memerlukan langkah tambahan.

Temukan Jalur Migrasi Anda Berdasarkan Versi Gitea

Jalankan gitea --version, temukan baris Anda, dan ikuti jalur di kolom ketiga. Semua hal lain dalam panduan ini adalah detail di balik baris-baris tersebut.

Pernyataan kompatibilitas versi ini berasal langsung dari pengumuman kompatibilitas resmi Forgejo: Gitea hingga v1.21 dapat berpindah ke Forgejo v7.0 sampai v10.0, dan Gitea v1.22 dapat berpindah ke Forgejo v8.0 sampai v10.0. Keduanya berhenti di v10.0 sebagai target langsung terakhir yang didukung.

Di balik pertanyaan versi ini terdapat tiga strategi migrasi, dan akan membantu untuk melihatnya sebelum masuk ke langkah demi langkah:

• Di tempat, server yang sama. Ganti binary atau image container pada server yang sudah ada. Upaya paling minim jika versi Anda mendukungnya; memerlukan langkah perantara v10.0.
• Staging di server baru. Siapkan server baru dan gunakan sebagai target yang aman untuk metode migrasi yang sesuai dengan versi Gitea Anda. Ini melindungi server Gitea asli dan mempermudah rollback, tetapi tidak menghindari masalah skema database Gitea 1.23+.
• Migrasi Repo/API. Gunakan tools migrasi Forgejo untuk menarik repositori dari instance Gitea lama. Riwayat Git adalah bagian yang andal; metadata seperti issue, PR, label, rilis, data wiki, dan komentar sebaiknya diperlakukan sebagai upaya terbaik dan diverifikasi repo demi repo.

Jalur yang Didukung: Gitea v1.22 atau Lebih Lama

Jika Anda menggunakan Gitea v1.22 atau lebih lama, maka dokumentasi migrasi resmi menjelaskan jalur dua langkah: migrasi ke Forgejo v10.0.x, lalu upgrade Forgejo v10 ke rilis terkini. Langkah pertama adalah penggantian drop-in karena Forgejo v10.x dapat membaca database Gitea v1.22; langkah kedua adalah upgrade Forgejo biasa.

Ada dua cara untuk melakukan ini tergantung bagaimana Gitea berjalan di server Anda. Pilih yang sesuai dengan setup Anda saat ini. Jika Gitea berjalan sebagai system service, gunakan jalur native. Jika Gitea berjalan di dalam container, gunakan jalur Docker. Forgejo v10.x berfungsi sebagai pengganti drop-in untuk Gitea v1.22.x.

Jalur Native (systemd)

Buat backup terlebih dahulu. Kemudian install Forgejo v10.0.x menggunakan paket distribusi Anda atau binary rilis yang dikunci ke v10.0. Hentikan Gitea sebelum Anda menyalin apa pun. Layanan yang masih berjalan dan menulis ke direktori datanya di tengah proses penyalinan akan merusak hasil salinan.

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

Salin konfigurasi dan direktori data ke lokasi Forgejo, lalu perbaiki kepemilikannya. File konfigurasi harus dapat dibaca oleh grup forgejo; data harus dimiliki oleh user 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

Jalankan Forgejo dan aktifkan agar berjalan saat boot.

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

Sebelum Anda upgrade dari v10.0, kosongkan antrean agar tidak ada pekerjaan yang sedang berjalan hilang selama lompatan versi.

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

Sekarang upgrade Forgejo v10.0.x ke rilis terkini dengan mengganti binary menggunakan v15 dan me-restart layanan, mengikuti Panduan upgrade Forgejo. Setelah kedua tahap tersebut, jalankan doctor untuk memeriksa database dan memperbaiki apa yang bisa diperbaiki.

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

Baca /tmp/doctor.log sebelum menerapkan perbaikan otomatis apa pun. Gunakan --fix hanya ketika output doctor mengidentifikasi perbaikan spesifik yang Anda pahami atau ketika Anda mengikuti jalur troubleshooting resmi.

Jika doctor melaporkan tidak ada error kritis dan UI web menampilkan repositories Anda, migrasi pertama sudah selesai.

Jalur Docker / Container

Jika Gitea berjalan sebagai container, jalankan Forgejo dengan cara yang sama. Gunakan image Forgejo v10.x sebagai pengganti langsung untuk image Gitea v1.22.x Anda, arahkan ke volume data dan database yang sama. Pastikan versi Docker Anda minimal 20.10.6 terlebih dahulu. Versi yang lebih lama menghasilkan perilaku yang tidak terduga pada container Forgejo.

Satu detail khusus container yang sering membuat orang tersandung: variabel environment. Forgejo mempertahankan prefiks GITEA_ demi kompatibilitas, tetapi dokumentasinya menyarankan untuk menyertakan kedua prefiks agar konfigurasi Anda tetap bertahan pada versi Forgejo mendatang yang menghapus nama lama.

# 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

Untuk container rootless, data harus dimiliki oleh user 1000 dan grup 1000, sesuai dengan runtime user dari image rootless tersebut. Setelah container berjalan pada v10.x, jalankan forgejo doctor check --all dari dalam container, lalu upgrade tag image ke rilis v15 terkini dan restart.

Jika Anda Menggunakan Gitea v1.23 atau Lebih Baru

Di sinilah panduan standar berhenti, dan di sinilah sebagian besar instalasi saat ini sebenarnya berada. Tidak ada jalur langsung yang didukung secara resmi dari Gitea v1.23+, sehingga setiap opsi di bawah ini bersumber dari komunitas atau berisiko kehilangan data. Sebelum menjalankan salah satunya, buat backup penuh dari direktori data dan database Anda, dan pastikan Anda bisa memulihkannya. Pendekatan-pendekatan ini mengubah data produksi; backup adalah satu-satunya cara Anda untuk membatalkannya.

Ketiga opsi ini berbeda dalam hal risiko dan seberapa banyak data yang dipertahankan. Pilih yang trade-off-nya bisa Anda terima.

Opsi A: Downgrade Skema SQL / Patch Versi

Workaround paling sempit adalah menurunkan versi skema database sehingga Forgejo v10 memperlakukannya sebagai database v1.22.

Catatan: Jangan memperlakukan update versi sebagai downgrade lengkap dengan sendirinya. Versi migrasi yang tercatat dan skema sebenarnya harus cocok. Pada Gitea 1.23.x, uji downgrade penuh pada salinan terlebih dahulu dan bandingkan skemanya sebelum mengarahkan Forgejo ke sana.

Seorang maintainer Forgejo menjelaskan SQL dalam Codeberg issue #7638:

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

Setelah ini, Anda mengikuti jalur yang didukung seolah-olah Anda berada di v1.22. Catatan pentingnya: maintainer hanya mengonfirmasi hal ini khusus untuk Gitea v1.23.1, bukan seluruh v1.23.x. Nomor versi skema harus tepat; menerapkan nilai target yang salah ke rilis Gitea yang salah dapat membuat database berada dalam kondisi yang tidak dapat dipulihkan oleh migrasi apa pun. Ini berlaku untuk PostgreSQL/MySQL, tidak didukung secara resmi, dan tidak diuji sebagai prosedur umum.

Tips Pro: Mengatur version=305 secara langsung akan melewati migrasi 304→305, yang mengubah cara secret TOTP dienkode. Codeberg issue #8210 mendokumentasikan bahwa hal ini merusak autentikasi dua faktor bagi pengguna yang terdampak. Perbaikannya adalah mengatur version ke 304, membiarkan migrasi berjalan, atau menghapus baris tabel two_factor sehingga pengguna mendaftar ulang. Jangan lewati langkah ini jika ada akun yang menggunakan TOTP.

Opsi B: Skrip Downgrade SQL Berurutan (Gitea 1.24–1.25.2)

Untuk versi antara 1.24 dan 1.25.2, satu patch versi saja tidak cukup: skema tersebut melewati beberapa keadaan perantara. Script komunitas di xlrl/prepare-gitea-migration-to-forgejo menurunkan skema secara bertahap melalui versi-versi perantara hingga ke v1.22, setelah itu Anda mengambil jalur yang didukung. Skrip-skrip ini adalah karya komunitas, bukan prosedur resmi, dan menyasar SQLite sebagai kasus utama. Jalankan hanya pada database yang sudah Anda backup.

Opsi C: Migrasi API Repo-per-Repo (Gitea 1.26+ atau Versi Apa Pun)

Jalur repo/API mempertahankan data Git dengan paling andal. Tergantung pada sumber, izin akses, dan metode migrasi, metadata opsional seperti issue, pull request, label, milestone, rilis, data wiki, dan komentar mungkin juga tersedia, tetapi perlakukan itu sebagai upaya terbaik dan verifikasi repo demi repo. Untuk arsip yang hanya berisi kode, ini biasanya cukup baik; untuk server yang issue tracker-nya menjadi memori tim, uji dulu transfer metadatanya sebelum memutuskan menggunakan jalur ini.

Dua alat eksperimental mencoba migrasi yang lebih lengkap untuk 1.23+, tetapi memiliki celahnya sendiri. pacnpal/gitea2forgejo (GitHub) melakukan dump penuh plus sinkronisasi API dan memerlukan SECRET_KEY yang cocok agar bidang terenkripsi dapat dipindahkan, tetapi tidak memindahkan Personal Access Tokens, Actions runners, URL callback webhook, atau 2FA. nicoverbruggen/gitea-to-forgejo (GitHub) adalah alat eksperimental berbasis Podman yang memindahkan users, keys, orgs, repos, issues, PRs, releases, dan mirrors, tetapi tidak memindahkan token 2FA, data runtime Actions, atau manifest paket OCI yang menggantung. Perlakukan keduanya sebagai eksperimental dan verifikasi hasilnya terhadap matriks transfer di bawah ini.

Inti bagian ini: tidak ada jalur langsung yang didukung secara resmi dari Gitea 1.23+. Pilih opsi dengan trade-off kehilangan data yang bisa Anda terima, dan lakukan backup sebelum memulai.

Migrasi di Server Baru Lebih Aman, tetapi Tidak Melewati Titik Kritis Versi

Server baru adalah tempat paling aman untuk menyiapkan dan memverifikasi migrasi, tetapi ini bukan jalur kompatibilitas skema yang terpisah. Jika sumber Anda adalah Gitea v1.22 atau lebih lama, install Forgejo v10.0.x di target terlebih dahulu, restore atau salin data Gitea ke sana, biarkan Forgejo menjalankan migrasi database yang didukung, lalu upgrade instance Forgejo v10 tersebut ke rilis Forgejo terkini.

Jika sumber Anda adalah Gitea v1.23 atau lebih baru, jangan mengembalikan database Gitea langsung ke Forgejo terkini dan berharap dapat berjalan. Anda tetap memerlukan salah satu pendekatan 1.23+ yang tidak didukung di atas: downgrade atau revert SQL bertahap, alat migrasi komunitas, atau migrasi repo/API. Server baru mengurangi risiko rollback karena server Gitea asli tetap tidak tersentuh; namun ini tidak menghilangkan kebutuhan untuk menangani ketidakcocokan versi database.

Di sinilah Forgejo satu klik dari Cloudzy aplikasi bisa membantu: gunakan sebagai instance target yang bersih, lalu jalankan metode migrasi yang sesuai dengan versi Gitea Anda. Image marketplace Cloudzy memberi Anda target Forgejo yang siap pakai di VPS berperforma tinggi, sehingga Anda dapat fokus pada langkah restore, verifikasi, dan cutover, alih-alih instalasi awal. Rencana migrasi tetap bergantung pada apakah Anda berada sebelum atau sesudah titik kritis Gitea 1.22.

Apa yang Berpindah dan Apa yang Harus Anda Lakukan Ulang

Sebagian data Anda berpindah secara otomatis, sebagian hanya berpindah jika suatu kondisi terpenuhi, dan sebagian lagi tidak pernah berpindah dan harus dibuat ulang secara manual. Mengetahui mana yang mana sebelum memulai adalah perbedaan antara cutover yang bersih dan seminggu penuh pengguna yang kebingungan.

Empat hal ini paling terdampak karena rusak secara diam-diam atau memengaruhi setiap user, jadi tangani dengan sengaja: user harus membuat ulang atau mengaudit Personal Access Tokens mereka, Anda harus mendaftarkan ulang Actions runners terhadap hostname baru, Anda harus menghapus indeks pencarian Bleve agar Forgejo membangunnya kembali dengan bersih, dan Anda harus menulis ulang uses: referensi singkat dalam workflow Actions Anda menjadi URL GitHub lengkap, karena Forgejo dan Gitea menarik action dari mirror yang berbeda dan referensi relatif akan mengarah ke tempat yang salah.

Tips Pro: Jika Anda menjalankan Gitea dan Forgejo secara paralel selama migrasi dan keduanya mengarah ke instance Redis yang sama, ubah Forgejo ke Redis db=1 sebelum memulai. Keduanya secara default menggunakan db=0, dan jika berbagi db yang sama, Gitea akan mengonsumsi event migrasi Forgejo dan merusak antrean migrasi. (blog.mei-home.net documents this exact failure.)

Inti bagian ini: Personal Access Tokens, runner Actions, deploy key per repo, dan indeks pencarian Bleve selalu harus ditangani secara manual. Jadwalkan sebagai tugas migrasi, bukan sebagai renungan belakangan.

Verifikasi Migrasi Berhasil

Mulailah dengan doctor, lalu periksa angka-angkanya, lalu uji hal-hal yang benar-benar dilakukan pengguna. Doctor menangkap masalah pada level database; pemeriksaan manual menangkap masalah kehilangan data dan akses yang tidak bisa dilihat oleh doctor.

1. Jalankan forgejo doctor check --all --log-file /tmp/doctor.log, lalu baca log sebelum membuat perubahan. Gunakan --fix hanya untuk perbaikan spesifik yang Anda pahami.
2. Pastikan jumlah repository, jumlah issue dan PR, serta jumlah objek LFS dan ukuran totalnya sesuai dengan angka sebelum migrasi Anda. Ketidakcocokan di sini berarti ada sesuatu yang tidak berhasil dipindahkan.
3. Uji push dan pull lewat SSH. Jika klien mendapatkan host-key mismatch, berarti Anda belum menyalin /etc/ssh/ssh_host_* ke server baru.
4. Masuk dan pastikan 2FA berfungsi untuk akun yang menggunakannya. Jika TOTP rusak, lihat catatan Opsi A di atas.
5. Buat ulang Personal Access Tokens, daftarkan ulang runner Actions, dan jalankan workflow uji coba.

Beberapa gejala pasca-migrasi memiliki penyebab yang sudah diketahui. Favicon atau logo yang hilang berarti aset branding Anda masih berada di public/assets/img/, bukan di custom/, tempat Forgejo sekarang mengharapkannya. Error 404 pada rute paket menunjukkan jalur penyimpanan yang salah konfigurasi. Actions yang gagal dengan pesan "repository not found" adalah uses: masalah mirror. Beralihlah ke URL lengkap. Halaman kosong atau error 500 setelah login pada database SQLite berarti Anda berada di bawah minimum, yang mana dokumentasi upgrade menempatkannya di Forgejo v1.19.3-0.

Kapan Masuk Akal untuk Tetap Menggunakan Gitea

Migrasi adalah pilihan, bukan kewajiban. Jika Anda sudah melewati titik kritis dan kompleksitas migrasi lebih besar daripada manfaat tata kelola atau fitur untuk situasi Anda, tetap menggunakan Gitea adalah pilihan yang sah. Gitea dikelola secara aktif (beberapa rilis per bulan, saat ini di v1.26.4), dan CommitGo menawarkan opsi komersial termasuk Gitea Enterprise, Gitea Cloud, dan sertifikasi SOC 2 Type 2 bagi tim yang membutuhkannya.

Ada juga masalah versi perantara EOL yang perlu dipertimbangkan secara jujur. Jalur langsung yang didukung mengharuskan Anda menginstal Forgejo v10.0 secara singkat, yang telah EOL sejak April 2025. Itu bisa diterima sebagai langkah migrasi sementara yang segera Anda tinggalkan lewat upgrade, tetapi sebagian operator akan keberatan atas dasar kebijakan. Bagi mereka, migrasi repo/API ke instance Forgejo baru bisa sepenuhnya menghindari langkah EOL ini, sementara staging server baru tetap bergantung pada metode migrasi yang Anda pilih.

Jika alasan Anda untuk berpindah adalah aktivitas pengembangan, data mendukung Forgejo sebagai proyek yang lebih aktif: sebuah analisis oleh honeypot.net menghitung 3,039 commit Forgejo berbanding 1,228 commit Gitea sepanjang Juli 2024 hingga Mei 2025, serta 232 kontributor Forgejo berbanding 153 kontributor Gitea selama setahun yang berakhir Mei 2025. Itu adalah satu sinyal di antara beberapa sinyal lain; pertimbangkan terhadap risiko migrasi Anda, bukan menganggapnya sebagai penentu mutlak.

Inti bagian ini: migrasi bukanlah keharusan. Keputusannya adalah soal preferensi tata kelola dan aktivitas yang dipertimbangkan terhadap risiko migrasi, dan kedua pilihan sama-sama bisa dipertanggungjawabkan.

Pilih Jalur Anda dan Backup Dulu

Jalur migrasi Anda pada akhirnya bergantung pada satu angka: versi Gitea Anda. Pada v1.22 atau lebih lama, Anda mengambil jalur dua langkah yang didukung melalui Forgejo v10. Pada v1.23 atau lebih baru, Anda memilih workaround berdasarkan kehilangan data yang bisa Anda terima: downgrade SQL/skema, skrip komunitas, migrasi repo/API, atau migrasi staging server baru. Jalur mana pun yang Anda ambil, backup dulu direktori data dan database Anda, lalu jalankan forgejo doctor setelahnya, dan pastikan jumlah repositori, issue, dan LFS Anda cocok dengan yang Anda mulai.

Identifikasi versi Anda, buat backup, dan ikuti baris yang sesuai. Jalurnya memang lebih rumit daripada yang dijanjikan tutorial lama, tetapi sudah jelas terdefinisi begitu Anda tahu posisi Anda pada titik kritis versi tersebut.

Pertanyaan yang Sering Diajukan

Bisakah Saya Upgrade Langsung dari Gitea ke Forgejo?

Ya, jika Anda menjalankan Gitea v1.22 atau lebih lama: upgrade langsung ke Forgejo v10.0, lalu upgrade Forgejo v10 ke rilis terkini. Tidak, jika Anda menjalankan Gitea v1.23 atau lebih baru. Forgejo v10.0 adalah rilis terakhir yang mendukung upgrade langsung secara transparan, sehingga versi Gitea yang lebih baru memerlukan workaround.

Versi Gitea Apa yang Kompatibel dengan Forgejo?

Gitea v1.22 dan versi sebelumnya memiliki jalur upgrade langsung yang didukung ke Forgejo (hingga Forgejo v10.0, lalu berlanjut ke versi terkini). Gitea v1.23 dan versi yang lebih baru tidak memiliki jalur langsung yang didukung secara resmi, karena Forgejo berhenti mendukung upgrade transparan dari Gitea v1.23+ sejak rilis setelah v10.0.

Bisakah Saya Migrasi dari Gitea 1.26 ke Forgejo?

Ya, tetapi tidak melalui upgrade langsung yang didukung. Opsi Anda adalah migrasi repo/API, di mana riwayat Git adalah bagian yang andal dan metadata harus diuji repo demi repo, skrip migrasi eksperimental, atau migrasi staging server baru menggunakan salah satu metode 1.23+ yang tidak didukung di atas. Tidak ada jalur in-place yang didukung secara resmi dari Gitea 1.26.

Apakah Personal Access Tokens Saya Ikut Berpindah?

Rencanakan untuk membuat ulang atau merotasi Personal Access Tokens setelah migrasi. Beberapa jalur migrasi tidak mempertahankannya, dan bahkan ketika token tetap ada, pengguna sebaiknya mengaudit scope-nya sebelum mengandalkannya lagi. Setiap skrip atau integrasi yang menggunakan token lama harus diuji dan diperbarui setelah cutover.

Apakah Workflow Gitea Actions Saya Berfungsi di Forgejo?

Sebagian besar ya, dengan dua perbaikan yang diperlukan. Workflow uses: referensi singkat akan rusak karena Forgejo dan Gitea menarik action dari mirror yang berbeda. Ubah menjadi URL GitHub lengkap (misalnya, uses: https://github.com/sammcj/dotenv-output-action@main). Anda juga harus mendaftarkan ulang Actions runners Anda, karena token registrasinya terikat pada hostname lama.

Bagaimana dengan Migrasi dari Gogs ke Forgejo?

Itu adalah migrasi berbeda dengan jalur berbeda dan di luar cakupan panduan ini. Panduan ini secara khusus membahas Gitea ke Forgejo; untuk sumber Gogs, rujuk dokumentasi migrasi resmi Forgejo untuk prosedur khusus Gogs.