Roku memindahkan seluruh repositori developer-nya dari GitHub ke GitLab, dan pengumuman resminya terbit 15 Oktober 2026. Repositori dokumentasi, sample app, dan tooling kini berada di gitlab.com/rokudev dengan nama repo yang tidak berubah. Bagi tim yang menyimpan URL repo Roku di skrip build, submodule, atau basis pengetahuan internal, ini pekerjaan yang harus dikerjakan sekarang, bukan nanti.
TL;DR
- Host berpindah dari github.com/rokudev ke gitlab.com/rokudev, nama repo tetap sama.
- Clone lokal harus diarahkan ulang lewat git remote set-url, bukan di-clone ulang dari nol.
- Submodule, pipeline CI, dan pemanggilan artefak rilis adalah tiga titik yang paling sering terlewat.
- Fitur Suggest edits tidak tersedia di GitLab, kontribusi dokumen lewat merge request.
Apa yang sebenarnya berpindah dan kapan?
Yang berpindah adalah repositori developer: dokumentasi developer, sample app, dan tooling pendukung. Pengumuman di blog Roku bertanggal 15 Oktober 2026, dan pengumuman resmi di forum developer menyusul pada 16 Oktober 2026 pukul 01.55 UTC, ditulis oleh akun staf Roku dan disematkan sampai 1 November 2026.
Nama repositori tidak berubah. Repo yang dulu berada di github.com/rokudev/
Yang terasa adalah lapisan otomasi. Setiap sistem yang menyimpan URL repo sebagai data, bukan sebagai tautan yang dibaca manusia, perlu diperbarui. Itu mencakup skrip bootstrap, konfigurasi CI, Dockerfile yang mengunduh dari git, sampai indeks pencarian internal yang melakukan crawl berkala.
Perpindahan host seperti ini bukan peristiwa langka di ekosistem open source. Yang membuatnya layak diperhatikan adalah cakupannya: dokumentasi, sample, dan tooling berarti tiga jenis konsumen berbeda, yaitu manusia, mesin build, dan sistem pencarian. Ketiganya punya cara sendiri untuk menyimpan URL.
| Objek | Sebelum 15 Oktober 2026 | Setelah migrasi |
|---|---|---|
| Halaman repo | github.com/rokudev/nama-repo | gitlab.com/rokudev/nama-repo |
| URL clone | https://github.com/rokudev/nama-repo.git | https://gitlab.com/rokudev/nama-repo.git |
| Raw file | Domain GitHub | Domain GitLab, alamat ikut berubah |
| Saran perbaikan dokumen | Fitur Suggest edits | Merge request ke repo dev-doc |
Bagaimana cara memperbarui clone dan submodule?
Caranya dengan mengubah URL remote pada clone yang sudah ada, lalu menyinkronkan submodule. Clone ulang dari nol bukan langkah pertama, karena riwayat lokal, branch kerja, dan stash akan hilang tanpa alasan yang kuat.
Langkah pertama, periksa remote yang terpasang. Kalau masih menunjuk ke GitHub, ubah ke GitLab dengan perintah berikut, ganti nama-repo sesuai repo yang dipakai.
git remote -v
git remote set-url origin https://gitlab.com/rokudev/nama-repo.git
git remote -vLangkah kedua, perbarui submodule. Berkas .gitmodules menyimpan URL, jadi mengubah remote induk saja tidak cukup. Setelah .gitmodules diedit, jalankan sinkronisasi agar konfigurasi lokal mengikuti.
git submodule sync --recursive
git submodule update --init --recursiveLangkah ketiga, verifikasi bahwa fetch benar-benar bekerja. Perintah git fetch pada remote baru adalah bukti paling murah. Kalau fetch berhasil dan daftar branch muncul, berarti kredensial, DNS, dan URL semuanya sehat. Jangan menunggu sampai pipeline gagal untuk mengetahui hal ini.
Untuk tim yang memakai banyak repo, urutan yang lebih aman adalah mengubah satu repo, menjalankan build, lalu melanjutkan ke repo berikutnya. Mengubah semuanya sekaligus membuat kegagalan build sulit dilokalisasi, karena setiap repo punya dependensi dan cache sendiri.
Apa yang paling sering terlewat saat migrasi remote git?
Yang paling sering terlewat adalah tempat URL disimpan sebagai data, bukan sebagai tautan. Pipeline CI, cache artefak, dan manifest dependensi adalah tiga tempat pertama yang perlu diperiksa.
Pipeline CI menyimpan URL di dua lapis: definisi job dan variabel lingkungan. Mengubah definisi job saja tidak cukup kalau ada variabel yang menyimpan host lama. Variabel ini biasanya diwarisi dari template organisasi, jadi pencarian harus mencakup template, bukan hanya berkas pipeline proyek.
Cache artefak menyimpan hasil build lama yang dibuat dari sumber lama. Setelah URL berubah, cache itu masih bisa dipakai dan memberi ilusi bahwa semuanya normal, sampai suatu hari cache kedaluwarsa dan build berikutnya gagal. Untuk migrasi host, langkah yang lebih jujur adalah membuang cache terkait lalu membangun ulang dari awal, supaya kegagalan muncul saat masih ada orang yang mengawasi.
Manifest dependensi mencakup hal yang mudah terlewat: entri yang menunjuk langsung ke git, misalnya dependensi yang dideklarasikan dengan URL repo plus tag. Entri seperti ini tidak muncul di daftar paket biasa karena bukan paket registry. Pencarian sederhana dengan pola host lama di seluruh berkas lock biasanya cukup untuk menemukannya.
Selain tiga hal itu, ada dua tempat lain yang sering luput. Pertama, dokumentasi internal: runbook, halaman onboarding, dan catatan insiden yang menyebut perintah clone. Kedua, bookmark dan tautan di alat kolaborasi, termasuk tautan permanen ke baris kode tertentu yang sekarang menunjuk ke host yang salah.
Apakah kontribusi dokumentasi masih bisa dilakukan?
Bisa, tetapi alurnya berubah. Roku menyatakan bahwa saran perbaikan dokumentasi tetap diterima, namun fitur Suggest edits tidak didukung di GitLab. Kontributor harus meminta akses ke repo dev-doc, melakukan fork, lalu mengirim merge request.
Perbedaan ini penting untuk tim yang punya kebiasaan mengirim koreksi kecil langsung dari halaman dokumentasi. Alur satu klik itu hilang, dan digantikan alur yang lebih mirip kontribusi kode: fork, branch, commit, merge request. Untuk koreksi salah ketik, langkahnya terasa lebih berat, tetapi hasilnya lebih mudah dilacak karena setiap perubahan punya diskusi dan riwayat.
Dari sisi pemelihara, alur merge request juga lebih rapi. Setiap usulan datang sebagai diff yang bisa diuji, bukan sebagai catatan bebas yang harus ditafsirkan. Untuk dokumentasi teknis yang menyangkut SDK, diff jauh lebih berguna karena perubahan satu kata bisa mengubah arti sebuah parameter.
Apa dampaknya untuk indeks internal dan agen kode?
Dampaknya nyata, dan Roku menyebutnya eksplisit. Kalau organisasi mengindeks repositori Roku untuk basis pengetahuan, asisten, atau agen kode, sumber URL harus diperbarui dan proses crawl dijalankan ulang, termasuk karena URL berkas mentah ikut berpindah.
Ini kelas masalah yang sering diabaikan karena tidak menimbulkan error. Indeks lama tetap menjawab, tetapi jawabannya berasal dari snapshot sebelum migrasi. Kalau ada perubahan dokumentasi setelah 15 Oktober 2026, pengguna internal akan mendapat versi lama tanpa tanda apa pun bahwa datanya basi.
Langkah yang masuk akal: catat tanggal migrasi sebagai penanda, perbarui daftar sumber, jalankan crawl ulang, lalu bandingkan jumlah dokumen sebelum dan sesudah. Kalau jumlahnya turun drastis, ada sumber yang gagal diambil dan perlu diperiksa. Kalau jumlahnya naik, kemungkinan ada duplikat karena sumber lama dan baru sama-sama terindeks.
Untuk agen kode yang memakai pencarian berbasis simbol, perubahan host juga memengaruhi pemetaan berkas. Path yang disimpan di indeks biasanya memuat host sebagai bagian dari identitas dokumen. Tanpa crawl ulang, hasil pencarian akan menunjuk ke lokasi yang tidak lagi bisa dibuka, dan pengguna melihat tautan mati meski isinya masih benar di tempat lain.
Apa risikonya kalau URL lama masih dipakai?
Risikonya bukan error langsung, melainkan kegagalan yang datang terlambat. Selama host lama masih melayani permintaan, semuanya tampak normal, dan justru itu yang membuat migrasi seperti ini berbahaya.
Skenario paling umum: sebuah pipeline berjalan sukses selama berminggu-minggu karena masih menarik data dari host lama, lalu gagal pada suatu malam ketika host itu berhenti melayani atau ketika repo lama berhenti diperbarui. Kegagalannya muncul di waktu yang paling tidak nyaman, dan penyebabnya tidak terlihat karena tidak ada yang berubah di sisi konfigurasi.
Skenario kedua lebih halus: build tetap berhasil, tetapi memakai kode lama. Untuk dokumentasi dan sample app, ini berarti tim mengikuti contoh yang sudah tidak sesuai dengan versi SDK terbaru. Kesalahannya tidak muncul sebagai error, melainkan sebagai bug yang sulit dijelaskan karena kodenya mengikuti dokumentasi resmi yang ternyata basi.
Karena itu, migrasi remote sebaiknya diperlakukan sebagai perubahan konfigurasi yang punya tenggat, bukan sebagai pembersihan opsional. Tetapkan tanggal, cari semua referensi ke host lama, ubah, lalu jalankan build penuh. Setelah itu, hapus akses ke host lama kalau memungkinkan, supaya sisa referensi yang terlewat langsung terlihat sebagai kegagalan, bukan sebagai kebetulan yang berhasil.
Untuk organisasi yang mengelola banyak repo pihak ketiga, perubahan host seperti ini juga menjadi alasan untuk meninjau kebijakan pencerminan. Repo yang dicerminkan ke host internal harus diperbarui sumbernya, karena cermin yang berhenti menyinkronkan tetap terlihat sehat sampai seseorang membandingkan commit terakhirnya dengan sumber asli.
Ada satu pemeriksaan murah yang jarang dilakukan: cari host lama di seluruh riwayat skrip, bukan hanya di berkas yang aktif. Skrip yang sudah tidak dipakai tetapi masih tersimpan di repo akan hidup lagi ketika seseorang menyalinnya untuk tugas baru, dan saat itu URL lama ikut terbawa.
FAQ
Apakah nama repositori Roku berubah setelah pindah ke GitLab?
Tidak. Pengumuman resminya menyebut nama repo tidak berubah, hanya host yang berpindah. Repo yang dulu di github.com/rokudev sekarang ada di gitlab.com/rokudev dengan nama yang sama.
Apakah repo di GitHub sudah dihapus?
Pengumuman Roku menyatakan migrasi telah selesai dan tautan dokumentasi sudah diarahkan ke GitLab, tetapi tidak menyatakan bahwa repo lama dihapus. Perlakukan GitHub sebagai sumber yang tidak lagi dijamin mutakhir dan pindahkan referensi ke GitLab.
Bagaimana cara mengubah URL remote tanpa clone ulang?
Gunakan git remote set-url origin diikuti URL GitLab repo tersebut, lalu verifikasi dengan git remote -v dan git fetch. Untuk submodule, edit .gitmodules lalu jalankan git submodule sync --recursive.
Apakah saya perlu mengubah pipeline CI?
Perlu, kalau pipeline melakukan clone, mengambil artefak rilis, atau memasang paket dari URL git. Periksa juga variabel lingkungan yang menyimpan host lama, karena nilai itu sering diwarisi dari template organisasi.
Di mana pengumuman resminya?
Ada dua sumber: artikel blog developer Roku bertanggal 15 Oktober 2026, dan pengumuman di forum developer yang terbit 16 Oktober 2026 dan disematkan sampai 1 November 2026.
💬 Komentar (0)
Belum ada komentar. Jadilah yang pertama! 💬