Transisi GitHub Actions ke Ubuntu 26.04: Memeriksa Perbedaan Runner Menggunakan Komit yang Sama Terlebih Dahulu
Hasil CI dapat berubah meskipun kode sumber tidak diubah. Jika alur kerja (workflow) Anda mengandalkan ubuntu-latest sebagai lingkungan eksekusi, transisi image sistem operasi juga harus dimasukkan ke dalam daftar perubahan yang dikelola oleh tim.
GitHub mengumumkan dukungan resmi untuk runner Ubuntu 26.04 dan rencana transisi ubuntu-latest pada 17 September 2026. Artikel ini bukan sekadar pengenalan bahwa image baru pasti lebih cepat, melainkan saran praktis untuk mengisolasi dan memverifikasi perbedaan lingkungan menggunakan komit yang sama.
Cakupan yang Dikonfirmasi dari Pengumuman Resmi
Menurut pengumuman tersebut, image Ubuntu 26.04 didukung secara resmi pada x64 dan arm64 dengan label eksplisit ubuntu-26.04 dan ubuntu-26.04-arm. ubuntu-latest dijadwalkan berpindah secara bertahap dari Ubuntu 24.04 ke 26.04 antara 19 Oktober hingga 19 November 2026.
Image baru ini memiliki alat yang diperbarui atau dihapus, sehingga build yang bergantung pada paket pra-instal mungkin akan terpengaruh. Jika persiapan belum selesai, GitHub menyarankan untuk menentukan ubuntu-24.04 secara eksplisit. Jadwal ini tidak serta-merta mencerminkan tanggal migrasi aktual untuk setiap repositori.
Mendokumentasikan Lingkungan yang Diharapkan oleh Repositori
Pertama, periksa runs-on di alur kerja utama maupun alur kerja yang dapat digunakan kembali (reusable workflows). Jangan berasumsi bahwa pengaruh host hilang hanya karena Anda menggunakan container; sebaiknya tinjau juga langkah-langkah instalasi, kompresi, dan pengunggahan yang berjalan di luar container.
Cobalah membagi daftar periksa ke dalam compiler, runtime, package manager, dan pustaka sistem. Daripada hanya mencatat nama alat, hubungkan dari mana alat tersebut diinstal dan langkah mana yang memanggilnya, agar lebih mudah mempersempit penyebab log kegagalan.
Komit yang Sama, Dua Lingkungan, Artefak Terpisah
Uji coba transisi sebaiknya dimulai dari jalur pengujian yang tidak memiliki izin deployment agar lebih jelas. Jalankan komit dan lockfile yang sama pada image lama serta image baru, lalu simpan log, hasil pengujian, dan nama artefak secara terpisah. Ini adalah metode verifikasi yang diusulkan dalam artikel ini.
Pada perbandingan awal, catat kondisi cache agar Anda dapat membedakan dampak dari cache lama. Selain status keberhasilan build, catat juga versi alat yang terinstal, langkah yang gagal, dan hasil eksekusi artefak untuk membedakan hasil yang lolos secara kebetulan berkat cache hit.
Verifikasi yang Tersisa di Balik Centang Hijau
Untuk proyek web, Anda dapat memeriksa apakah file yang dihasilkan benar-benar dapat disajikan; jika terdapat dependensi native, pastikan dependensi tersebut dapat dimuat di lingkungan target. Alih-alih menerapkan aturan bahwa setiap byte artefak harus identik, pisahkan perbedaan non-deterministik seperti timestamp dari perbedaan fungsional dalam penilaian Anda.
Peninjau harus dapat melihat tautan eksekusi image baru, perbedaan versi alat, hasil pemeriksaan fitur representatif, dan perubahan yang perlu dibatalkan di satu tempat. Menggabungkan transisi runner dengan refaktorisasi aplikasi hanya akan memperluas penyebab kegagalan dan cakupan rollback secara tidak perlu.
Keuntungan dan Keterbatasan dari Menyematkan Image
Label sistem operasi yang eksplisit membantu mengontrol transisi besar, tetapi bukan berarti lingkungan build menjadi sepenuhnya tidak dapat diubah (immutable). Tetap biasakan untuk menginstal alat yang dibutuhkan secara eksplisit dan mencatat versi aktualnya ke dalam log.
Untuk repositori kecil, tidak perlu membuat sistem verifikasi yang masif dari awal. Anda bisa mulai dengan membandingkan satu build representatif dan dependensi yang paling sensitif, serta jika melakukan penyematan sementara, catat penanggung jawab pelepasan dan tanggal peninjauan kembali.
Memisahkan Diskusi Publik dari Keputusan Tim Kita
Issue publik di runner-images adalah tempat untuk memeriksa perubahan image dan laporan masalah. Komentar tertentu atau kegagalan pada proyek lain tidak selalu terjadi di repositori Anda, dan artikel ini tidak mengklaim konsensus komunitas atau frekuensi insiden dalam bentuk angka.
Langkah yang perlu dilakukan hari ini adalah menemukan di mana label latest digunakan dan menguji komit yang sama pada image baru. Dengan menentukan kriteria lolos dan kriteria penundaan terlebih dahulu, penanggung jawab dapat menilai berdasarkan bukti yang konsisten meskipun perilaku build berubah selama periode transisi aktual.