Pindah dari GitHub ke Codeberg, cara untuk orang malas

• Saat memindahkan beberapa proyek dari GitHub ke Codeberg, tulisan ini merangkum cara memulai migrasi dengan usaha seminimal mungkin
• Melalui fitur import repositori di Codeberg, migrasi penuh termasuk issue, PR, dan rilis beserta artefaknya dimungkinkan, dan UI serta alur kerjanya mirip dengan GitHub
• Hosting halaman statis bisa digantikan dengan codeberg.page, dan ada juga alternatif seperti grebedoc.dev atau statichost.eu
• Tantangan terbesar adalah menyiapkan lingkungan CI, karena harus melepas runner macOS GitHub dan kuota eksekusi gratisnya, lalu menggantinya dengan Forgejo Actions atau Woodpecker CI
• Setelah migrasi, repositori GitHub bisa dipertahankan sebagai arsip read-only atau mirror, sehingga hubungan dengan ekosistem open source tidak sepenuhnya terputus

---

Proses pindah dari GitHub ke Codeberg

• Berdasarkan pengalaman mulai memindahkan beberapa repositori dari GitHub ke Codeberg, tulisan ini menjelaskan tingkat kesulitan dan kemudahan proses migrasi nyata
  • Sebelumnya migrasi ditunda karena mengira Codeberg belum cukup siap, tetapi tergantung proyeknya, perpindahan ternyata bisa jauh lebih mudah dari dugaan
  • Tujuannya bukan menyiapkan konfigurasi yang sempurna, melainkan menemukan cara termudah untuk mulai pindah

• Migrasi repositori dan issue

  • Codeberg menyediakan fitur import repositori GitHub, sehingga issue, PR, rilis, dan artefaknya dapat ikut dipindahkan
    • Dalam proses ini, nomor issue, label, dan informasi penulis tetap dipertahankan
    • UI Codeberg hampir sama dengan GitHub, dan pengalamannya jauh lebih sederhana dibanding prosedur rumit yang biasanya diperlukan saat pindah dari issue tracker lain ke GitHub

• Hosting halaman statis

  • Jika sebelumnya memakai GitHub Pages, codeberg.page bisa digunakan sebagai pengganti
    • Memang tidak ada jaminan ketersediaan resmi (SLO), tetapi disebut belum pernah mengalami downtime dalam praktiknya
    • Strukturnya mirip GitHub Pages, dengan cara mendorong HTML ke sebuah branch
    • Alternatif lain yang bisa dipakai adalah grebedoc.dev atau statichost.eu

• Tantangan lingkungan CI (continuous integration)

  • Bagian paling rumit dalam migrasi adalah membangun lingkungan CI
    • GitHub menyediakan runner macOS gratis dan kuota eksekusi tak terbatas untuk repositori publik, tetapi hal ini harus dilepas jika pindah ke Codeberg
    • Sebagai solusi, bisa memanfaatkan cross-compilation per bahasa dan self-hosting runner Forgejo Actions

  • Forgejo Actions vs Woodpecker CI

    • Di Codeberg, Woodpecker CI lebih stabil, tetapi Forgejo Actions memberi pengalaman yang lebih akrab bagi pengguna GitHub Actions
    • UI dan sintaks YAML hampir sama, sehingga sebagian besar workflow GitHub Actions yang sudah ada bisa langsung berjalan
    • Contohnya, bagian yang sebelumnya memakai uses: dtolnay/rust-toolchain di GitHub Actions dapat diubah di Forgejo Actions menjadi uses: https://github.com/dtolnay/rust-toolchain
    • Saat ini dokumentasi Forgejo Actions di Codeberg belum sepenuhnya mutakhir, dan sudah ada PR terkait hal tersebut

  • Jika memerlukan runner macOS

    • Jika build macOS benar-benar diperlukan, GitHub Actions bisa tetap digunakan, lalu commit dari repositori Codeberg dimirror ke GitHub
    • Forgejo Actions dapat diatur untuk melakukan polling ke GitHub API agar status CI disinkronkan ke Codeberg
    • Layanan CI lain yang menyediakan build macOS juga sudah dicoba, tetapi integrasinya dengan Codeberg tidak sesederhana GitHub Actions

• Cara menangani repositori GitHub

  • Setelah pindah, repositori GitHub diedit README-nya lalu diarsipkan
    • Repositori juga bisa diatur agar mendorong commit dari Codeberg ke GitHub, tetapi dalam kasus ini pengguna masih bisa membuat PR dan menulis komentar issue
    • Sebagian orang menonaktifkan fitur issue di repositori GitHub, tetapi ini membuat semua issue hilang sebagai 404, dan PR tidak bisa dinonaktifkan
    • Sebagai contoh, repositori libvirt/libvirt memakai GitHub Action yang otomatis menutup semua PR
  • Pendekatan seperti ini bisa memberi dampak negatif pada self-hosting dan ekosistem open source secara keseluruhan
    • Pengguna bisa kehilangan motivasi untuk memperbaiki optimasi build atau frekuensi unduhan file rilis
    • Selama masa transisi, opsi seperti mempertahankan mirror read-only atau tetap memakai GitHub Pages dan Actions secara paralel juga patut dipertimbangkan

[GN⁺]

Komentar Hacker News

• Saya tidak membenci Codeberg itu sendiri, tetapi ini bukan pengganti penuh GitHub
  Ada banyak keterbatasan untuk mengunggah repositori kode pribadi atau skrip eksperimen, dan repositori privat dibatasi hingga 100MB
  Juga tidak bisa meng-host homepage seperti GitHub Pages. Untuk penggunaan seperti ini, alternatif yang realistis adalah self-host Forgejo secara langsung
  Hal terkait ini dirangkum dengan baik di FAQ Codeberg

  • Di Codeberg juga bisa meng-host homepage melalui fitur Codeberg Pages
  • Saya juga menjalankan situs web saya di Codeberg Pages. Informasi di atas salah → dokumentasi Codeberg Pages
  • Sulit setuju dengan pernyataan “menjalankan server git sendiri itu memberatkan”. Jika hanya ingin tempat untuk push kode, satu server SSH saja sudah cukup
  • Proyek Code Storage buatan Pierre menarik sebagai server git berbentuk API yang mengurangi beban operasional seperti ini
  • (Sekalian promosi) Saya sedang mengembangkan alternatif GitHub bernama Monohub. Mendukung repositori privat secara default dan juga PR. Contoh repositori publik

• Alasan saya menaruh proyek OSS di GitHub itu sederhana — karena komunitasnya ada di sana
  Kalau cuma untuk menaruh kode, saya akan host sendiri lewat SSH atau SFTP

  • Komunitas yang hanya bertahan di GitHub adalah masalah ayam atau telur lebih dulu. Pada akhirnya seseorang harus pindah lebih dulu ke platform lain agar ekosistem ikut bergerak
    Saya hanya mengunggah ke instance Gitea pribadi saya, dan tidak peduli pada bintang atau promosi
  • Yang tetap tinggal di GitHub hanyalah komunitas FOSS yang menerima ketergantungan tertutup. Bahkan kebijakan GitHub justru mendorong orang untuk pergi
  • Beberapa proyek bahkan mustahil diikuti tanpa akun GitHub. Contohnya, isu crates.io belum terselesaikan selama 10 tahun, dan Reservoir milik Lean mensyaratkan setidaknya 2 bintang GitHub. Ini tampak seperti penguatan ketergantungan pada Microsoft
  • GitHub menyediakan banyak resource CI secara gratis. Terutama runner macOS yang hampir tidak punya alternatif. Berkat itu, pengujian di berbagai lingkungan jadi memungkinkan
  • Saya juga mulai hosting Git di home server untuk keluar dari GitHub, tetapi dopamin saat push commit seperti dulu sudah hilang. Rasanya open source kehilangan daya tariknya seiring makin dikomersialkan

• Saya mengelola semua proyek pribadi dengan Forgejo self-hosted. Sama sekali tidak merindukan GitHub
  Dengan Tailscale, akses bisa dibatasi sehingga crawler AI dapat diblokir

  • Saya juga sudah beberapa tahun menjalankan Forgejo sendiri. Bahkan menulis tutorial instalasi dan baru-baru ini pindah ke 2 Raspberry Pi di Hetzner. Lebih cepat dan stabil daripada GitHub
  • Dulu saya memakai GitLab, tetapi Forgejo jauh lebih ringan sebagai single binary Go sehingga konsumsi resource lebih rendah. Bisa dijalankan dengan mudah lewat Docker, dan seru juga mengutak-atik fiturnya sendiri
  • Saya menginstal Forgejo saat pembuatan akun agen diblokir di GitHub, lalu dalam 15 menit langsung menambahkan sendiri fitur “Hide viewed files” di review PR
  • Belakangan banyak proyek OSS besar pindah ke Forgejo, jadi saya ikut pindah juga, dan sejauh ini sangat puas
  • Saya juga memasang runner Forgejo lewat Docker untuk menjalankan CI. Ada registry bawaan, jadi aplikasi saya distribusikan sebagai image Docker

• Ke depan, mengevaluasi alternatif GitHub tampaknya akan makin penting
  Namun GitHub sudah menetapkan CI dan build multi-arsitektur sebagai standar, sehingga alternatif yang digerakkan komunitas sulit bersaing

  • CI tidak harus terikat pada GitHub. Pada dasarnya sebagian besar CI hanyalah eksekutor perintah sederhana. Untuk tim kecil, operasional tanpa CI pun sepenuhnya memungkinkan
  • Saya tidak paham kenapa menjalankan CI sendiri dianggap tidak rasional. Memisahkan repo dan CI juga tidak masalah
  • Bagi saya, yang penting bukan CI melainkan pengalaman PR dan code review. GitHub masih punya banyak bagian yang tidak nyaman, dan sistem issue-nya pun terasa seperti level 20 tahun lalu
  • Layer terpusat seperti ini pada akhirnya lahir dari hasrat untuk mengontrol. Dengan workflow terdistribusi yang berpusat pada lokal pun kita tetap bisa mengembangkan software dengan nyaman

• GitHub memang memberi banyak hal secara “gratis”, tetapi sebagai gantinya besar kemungkinan dipakai untuk pengumpulan data dan pelatihan
  Codeberg tidak mendukung repositori privat, jadi bahkan tidak bisa mencegah Copilot mengikis repositori publik
  Menurut FAQ Codeberg, jika butuh proyek privat maka disarankan self-host Forgejo

  • Namun repositori Codeberg saya disetel privat. Jadi tampaknya bukan sesuatu yang sepenuhnya mustahil

• Perusahaan kami sudah sepenuhnya pindah dari GitHub ke GitLab self-hosted
  Ditaruh di belakang Tailscale jadi tidak ada beban SSO, dan runner CI dijalankan di EKS serta klaster GPU. Saya bisa membantu orang yang sedang mempertimbangkan migrasi serupa

  • Penasaran apakah Forgejo juga sempat dipertimbangkan. GitLab kuat untuk CI/CD kelas enterprise, tetapi untuk proyek kecil Forgejo tampaknya pilihan yang lebih ringan
  • Saya juga penasaran apakah GitLab self-hosted mendukung fitur seperti provisioning pengguna otomatis (SCIM)

• Sekadar berkata “mari ganti GitHub” itu tidak berarti. Yang dibutuhkan adalah kebiasaan baru dan value proposition baru
  Seperti GitHub menggantikan SourceForge, platform generasi berikutnya harus menghubungkan penulisan kode dan kolaborasi secara real-time
  Misalnya bisa saja berbentuk seperti Google Docs, di mana setiap prompt menghasilkan commit

  • Namun ada juga faktor geopolitik yang besar. Di Eropa dan tempat lain, gerakan untuk menghindari ketergantungan pada teknologi AS makin aktif
  • Setelah kontroversi Copilot belakangan ini, kepercayaan goyah dan mulai muncul arus untuk meninggalkan GitHub
  • Bagi saya, yang penting bukan cuma fitur melainkan availability (uptime). Akhir-akhir ini GitHub bahkan terasa tidak sampai 99%

• Codeberg itu ideal, tetapi secara realistis punya masalah stabilitas yang besar
  Karena beroperasi tanpa Cloudflare, layanan ini rentan terhadap serangan DDoS dan sering mengalami downtime. Saat sedang mengembangkan sesuatu lalu tidak bisa mengakses remote repository, itu benar-benar menyebalkan

  • Saya memakai GitHub atau Codeberg hanya untuk berbagi kode secara asinkron. Bahkan jika remote mati, pekerjaan harus tetap bisa berjalan secara lokal
  • Saya tidak suka Cloudflare, tetapi secara realistis itu penting untuk pertahanan terhadap traffic bot dan serangan. Layanan alternatif justru lebih sering terblokir atau tidak stabil. Saya benar-benar merasakan jarak antara prinsip dan realitas
  • Jika melihat monitor uptime GitHub, dalam 90 hari terakhir justru ada di kisaran 90%. Malah Codeberg lebih stabil
  • Server git pribadi saya juga mengalami penurunan performa akibat scraping brutal dari crawler AI. Akhirnya saya memblokir semua IP dari perusahaan-perusahaan besar
  • Inti dari git adalah sifat terdistribusi. Meski remote mati, versi terbaru tetap harus ada di lokal

• Sejak diakuisisi Microsoft, saya hampir tidak pernah memakai GitHub. Saya justru menyukai workflow berbasis email yang sederhana dari Sourcehut
  Untuk CI pun saya rasa cukup jika berbentuk perintah yang bisa dijalankan secara lokal

• Repositori kode pada dasarnya harus memiliki struktur terdistribusi dan terfederasi
  Berkat sistem tanda tangan kriptografis (GPG/SSH) milik git, kepercayaan pada repositori dan kepercayaan pada commit bisa dipisahkan
  Pusat cukup menangani key server dan manajemen namespace, sementara sisanya bisa didistribusikan

  • Radicle adalah proyek yang memang menargetkan hosting git terdistribusi seperti ini
  • Tetapi kebanyakan developer tidak benar-benar mampu mengelola kunci tanda tangan dengan baik
  • Karena alasan ini, protokol federasi seperti Tangled dan ForgeFed sedang diintegrasikan ke Forgejo
  • git-bug juga pendekatan yang menarik. Saya belum mencobanya, tetapi tampak punya potensi