GitHub Actions cache-mode: Memeriksa Izin Cache di Balik CI Hijau
Jika CI selesai dengan warna hijau tetapi eksekusi berikutnya mengunduh ulang dependensi, Anda mungkin cenderung langsung memperbaiki kunci cache. Sekarang, Anda juga harus memeriksa apakah penyimpanan dilewati karena masalah izin. Pasalnya, fakta bahwa alur kerja berhasil tidak dapat dijadikan bukti bahwa cache telah dibuat.
GitHub mengumumkan ketersediaan umum cache-mode pada 10 September 2026. Di semua paket github.com, Anda dapat menentukan akses cache pada tingkat alur kerja atau pekerjaan (job). Melangkah lebih jauh dari artikel sebelumnya yang membahas nilai default hanya-baca, kali ini kita berfokus pada konfigurasi eksplisit dan metode verifikasi.
Fitur yang Dikonfirmasi: Empat Kombinasi Pemulihan dan Penyimpanan
read hanya mengizinkan pemulihan, sedangkan write mengizinkan pemulihan dan penyimpanan. write-only hanya mengizinkan penyimpanan dan none memblokir keduanya. Memastikan Anda tidak salah mengira nama write sebagai khusus penyimpanan adalah langkah pemeriksaan pertama.
Nilai yang dideklarasikan pada sebuah pekerjaan memiliki prioritas lebih tinggi daripada pengaturan seluruh alur kerja. Sebaliknya, dalam pemanggilan alur kerja yang dapat digunakan kembali, alur kerja tersebut tidak dapat menerima izin akses yang lebih besar daripada yang diizinkan oleh pemanggil. Jangan menilai izin aktual dari keseluruhan eksekusi hanya dengan membaca deklarasi dalam satu file saja.
Eksekusi Hijau Bukan Bukti Penyimpanan
Dokumentasi resmi menjelaskan bahwa operasi cache yang tidak diizinkan akan mencatat log informasi dan tetap melanjutkan proses. Pemulihan yang diblokir akan diperlakukan sebagai cache miss, dan penyimpanan yang diblokir tidak akan dilakukan. Fakta bahwa alur kerja itu sendiri tidak gagal adalah kunci dari observasi ini.
Oleh karena itu, ada baiknya memisahkan catatan operasional antara keberhasilan eksekusi dan hasil cache. Periksa dalam satu eksekusi mengenai peristiwa mana yang memicunya, mode mana yang diterapkan, apakah pemulihan berhasil, dan apakah penyimpanan dilewati. Ini adalah metode operasional yang disarankan berdasarkan deskripsi fitur resmi, bukan fitur dasbor baru yang disediakan secara otomatis.
Membuat Tabel Izin Sederhana Sebelum Penerapan
Buka alur kerja repositori Anda yang sebenarnya dan cari pekerjaan yang memproduksi cache serta yang mengonsumsinya. Anda tidak perlu menyatukan pekerjaan yang menyiapkan dependensi di cabang tepercaya, pekerjaan yang menguji perubahan eksternal, dan pekerjaan yang memvalidasi artefak deployment ke dalam izin yang sama.
Tuliskan dua pertanyaan untuk setiap pekerjaan: Apakah pekerjaan ini harus membaca cache yang ada? Bolehkah hasil dari pekerjaan ini disimpan agar dapat dibaca oleh eksekusi berikutnya? Jika keduanya tidak diperlukan, Anda dapat meninjau kembali kebiasaan memasang cache secara otomatis. Namun, konfigurasi sebenarnya harus diputuskan sesuai dengan batas kepercayaan repositori dan struktur build Anda.
Eksperimen Minimal: Pekerjaan Konsumsi Hanya-Baca
Sebagai contoh, tentukan cache-mode: read di tingkat teratas pada alur kerja pengujian dan pastikan tidak ada penimpaan (override) di tingkat pekerjaan. Bandingkan apakah hasil pengujian saat menggunakan cache sama dengan hasil pengujian tanpa cache. Karena cache seharusnya menjadi sarana bantu untuk mengurangi waktu eksekusi, jika ketiadaan cache mengubah akurasi pengujian, Anda harus memeriksa asumsi build terlebih dahulu.
Kriteria kelulusan untuk eksperimen ini bukan sekadar satu baris keberhasilan CI. Anda harus mampu menjelaskan upaya pemulihan dan dilewatinya penyimpanan, serta dapat memverifikasinya kembali pada eksekusi berikutnya dengan input yang sama. Mencatat commit sebelum dan sesudah eksperimen, pemicu, konfigurasi yang berlaku, serta lokasi log akan memudahkan rekan kerja lain mereproduksi pertimbangan tersebut.
Membaca Alur Pemanggilan pada Alur Kerja yang Dapat Digunakan Kembali
Meskipun Anda telah menetapkan nilai default yang aman pada alur kerja bersama, Anda tetap harus meninjau pihak pemanggil dan konfigurasi pekerjaan individual secara bersamaan. Fakta bahwa setiap repositori memanggil file yang sama tidak berarti file tersebut dijalankan dengan izin yang sama.
Saat melakukan peninjauan, mulailah dari pemanggil, lalu telusuri deklarasi cache pekerjaan, dan terakhir alur kerja yang dipanggil. Jika izin yang diharapkan berbeda dari log sebenarnya, cari sumber konfigurasi tersebut sebelum membuat kunci menjadi lebih rumit. Ini adalah saran untuk mengurangi waktu diagnosis dalam organisasi yang banyak menggunakan alur kerja bersama, dan bukan berarti angka peningkatan performa yang terukur.
Pengecualian yang Perlu Diperhatikan dan Urutan Penerapan
Menentukan write atau write-only pada peristiwa dengan tingkat kepercayaan rendah seperti pull_request_target dapat menimpa batasan default hanya-baca dan meningkatkan risiko kontaminasi cache. Dalam kasus ini, GitHub akan menambahkan anotasi peringatan. Anda harus menghindari respons seperti memperluas izin tulis hanya demi menghilangkan peringatan tersebut.
Sebaliknya, pilihan untuk memblokir semua cache juga memiliki konsekuensi biaya. Waktu pengunduhan dan build dapat meningkat, jadi bandingkan waktu eksekusi secara langsung pada satu pekerjaan representatif sebelum memperluas cakupannya. Daripada menjanjikan efek performa berdasarkan perkiraan angka, lebih baik tim menentukan bersama batasan keamanan yang diperlukan dan toleransi keterlambatan yang dapat diterima.
Pertanyaan yang Harus Diperiksa Tim Sekarang
Tugas hari ini bukanlah menambahkan konfigurasi baru secara massal ke seluruh repositori. Mulailah dengan menemukan produsen dan konsumen cache pada satu alur kerja penting, catat izinnya, dan verifikasi bukti pemulihan serta penyimpanan dalam satu kali eksekusi. Jika itu adalah pekerjaan deployment, pertahankan perubahan tetap kecil agar penanggung jawab dapat membaca log dan meninjau apakah hasilnya sesuai harapan.
Pertanyaan yang mungkin muncul dalam praktik adalah mengapa CI berhasil padahal langkah penyimpanan dilewati. Artikel ini menjelaskan kebingungan tersebut berdasarkan perilaku resmi, dan tidak mengklaim survei komunitas terpisah atau tingkat kegagalan umum. Dengan memeriksa hasil performa dan hasil izin secara terpisah saat mengadopsi fitur baru, Anda dapat mengklasifikasikan masalah cache berikutnya dengan lebih akurat.