Token stage-only npm: Bukti yang Harus Disimpan Saat Memisahkan Otomatisasi Penerbitan dan Persetujuan Akhir
Memisahkan izin CI untuk membuat paket dari izin untuk memublikasikannya kepada pengguna membuat tanggung jawab akhir rilis menjadi lebih jelas. Namun, menambahkan satu tombol persetujuan tidak serta-merta menghilangkan risiko rantai pasok. Anda harus terlebih dahulu menentukan apa yang perlu diperiksa oleh pemberi persetujuan.
GitHub mengumumkan pada 18 September bahwa izin tulis stage-only kini dapat dipilih pada granular access token npm. Alur kerjanya adalah otomatisasi mengirimkan versi ke status menunggu peninjauan, dan maintainer menyetujui publikasi melalui 2FA. Berikut adalah penjelasan yang membedakan antara perubahan resmi dan saran editorial untuk menerapkannya ke dalam operasional.
Memblokir Publikasi Langsung Berbeda dengan Menghapus Izin Tulis
Menurut panduan resmi, token tersebut dapat menjalankan npm stage publish, tetapi publikasi langsung melalui npm publish akan ditolak. Pembatasan ini tetap berlaku meskipun terdapat pengaturan bypass 2FA untuk otomatisasi. Fitur ini tidak mengubah perilaku token yang sudah ada secara otomatis dan diadopsi secara opsional.
Hal yang perlu diperhatikan adalah bahwa izin tulis paket lainnya, seperti pemindahan dist-tag dan depresiasi versi, tetap ada. Nama stage-only tidak boleh diartikan sebagai token hanya-baca atau token yang sepenuhnya tidak berbahaya. Cakupan paket yang diizinkan, lokasi penyimpanan rahasia, entitas pengguna, dan prosedur pencabutan tetap harus dikelola.
Menentukan Bundel Rilis yang Akan Dibandingkan oleh Pemberi Persetujuan
Poin-poin berikut bukanlah konfigurasi wajib npm, melainkan saran operasional untuk tim kecil. Sertakan commit sumber, paket dan versi target, hasil pengujian, daftar berkas yang disertakan dalam paket, serta ringkasan perubahan dalam satu permintaan persetujuan. Jika pemberi persetujuan harus mengumpulkan bukti dari berbagai log CI yang terpisah, peninjauan dapat dengan mudah berubah menjadi klik formalitas belaka.
Secara khusus, peninjauan kode sumber dan peninjauan berkas distribusi adalah dua hal yang berbeda. Berkas yang tidak ada di repositori bisa saja masuk selama proses build, atau berkas yang diperlukan bisa saja tertinggal. Tim dapat menetapkan prinsip untuk membuat materi tinjauan berdasarkan artefak yang benar-benar dikirimkan, dan memperlakukannya sebagai objek tinjauan baru jika artefak diubah setelah peninjauan.
Ada Status Menunggu Bahkan Setelah CI Berwarna Hijau
Jika otomatisasi sebelumnya melaporkan keberhasilan perintah sebagai rilis selesai, representasi statusnya harus diubah terlebih dahulu. Caranya adalah dengan membagi status menjadi pengiriman selesai, menunggu persetujuan, dan publikasi selesai, serta mencatat dasar verifikasi untuk masing-masing status. Dalam notifikasi, mencantumkan tahap saat ini dan penanggung jawab jauh lebih berguna bagi operator daripada sekadar kata sukses.
Sebagai contoh hipotesis, jika CI malam hari mengirimkan versi baru tetapi penanggung jawab baru meninjaunya keesokan harinya, pengumuman rilis kepada pengguna tidak boleh dikirim pada saat pengiriman dilakukan. Hubungkan alur kerja sehingga dokumentasi atau pengumuman dilanjutkan setelah verifikasi publikasi yang telah ditentukan tim. Harus disepakati juga sebelumnya mengenai siapa yang akan meninjau dan kapan harus membersihkan pengiriman sebelumnya ketika antrean menumpuk.
Memvalidasi Migrasi dengan Satu Paket Kecil
Prasyarat saat ini dalam panduan resmi mencakup paket npm yang sudah ada, izin publikasi paket, 2FA akun, npm CLI 11.15.0 atau lebih tinggi, dan Node.js 22.14.0 atau lebih tinggi. Sebelum migrasi sebenarnya, periksa kembali dokumentasi terbaru dan pastikan versi runner yang digunakan sudah sesuai.
Kami menyarankan untuk membatasi cakupan token pada satu paket dengan dampak kecil terlebih dahulu dan berlatih dari pengiriman staging, peninjauan maintainer, hingga verifikasi hasil publikasi. Jika kegagalan langsung dialihkan ke token lama dengan izin luas, batasan yang telah dipisahkan akan menjadi sia-sia. Keterlambatan persetujuan juga harus dapat ditangani sebagai status normal.
Pertanyaan untuk Membandingkannya dengan Trusted Publishing
npm juga menyediakan trusted publishing menggunakan OIDC. Langkah pertama adalah memeriksa apakah ini sesuai dengan lingkungan CI yang didukung dan metode persetujuan tim Anda, dan tidak ada alasan untuk menggeneralisasi token stage-only sebagai solusi akhir bagi setiap tim. Jika otomatisasi Anda harus terus menggunakan token, ini dapat dilihat sebagai opsi untuk bertransisi secara bertahap.
Pengumuman resmi menyebutkan Januari 2027 sebagai target penghapusan publikasi langsung untuk token bypass-2FA. Daripada berspekulasi tentang semua detail implementasi yang telah dikonfirmasi, lebih praktis untuk menyusun daftar alur kerja target dan penanggung jawab migrasi sekarang. Mengenai perubahan jadwal apa pun, periksa pengumuman resmi di masa mendatang.
Saat Memutuskan Penerapan
Artikel ini tidak mengklaim adanya konsensus komunitas yang luas atau tingkat pengurangan insiden nyata. Artikel ini mengusulkan prosedur operasional yang dapat ditinjau berdasarkan perilaku resmi dari fitur baru tersebut. Kemampuan untuk menjelaskan apa yang akan ditangani oleh otomatisasi dan apa yang harus diverifikasi oleh manusia adalah titik awal dalam memutuskan penerapannya.
Tindakan yang dapat dilakukan hari ini adalah menemukan tempat token rilis saat ini digunakan, menuliskan kondisi untuk menentukan penyelesaian publikasi, dan menetapkan bukti yang diperlukan untuk satu persetujuan. Batasan izin dan kualitas peninjauan harus ditangani bersama-sama agar tahap staging benar-benar bermanfaat.