Bangun wheel Python di luar jaringan, terbitkan di dalam

Anda sudah punya pekerjaan build yang menghasilkan wheel, dan repositori privat yang seharusnya menerimanya. Kesalahannya adalah membiarkan pekerjaan kedua membangun ulang dari cabang lalu menyebut hasilnya sebagai rilis yang sama. Pindahkan berkas yang sudah diuji, beri nama sesuai digest, dan simpan kredensial unggah di dalam. Uraian di bawah mengikuti satu artefak dari runner CI publik sampai ke penerbit internal.

Bangun di tempat kode sumber sudah berada

Jalankan build di pekerjaan yang sudah memiliki kode sumber, rangkaian alat, dan rangkaian uji. Tidak ada yang menuntut pekerjaan itu menjangkau repositori privat. Pasang frontend build di lingkungan yang sudah dipakai proyek, lalu hasilkan kedua format distribusi jika proyek mengirim keduanya.

python -m build --sdist --wheel --outdir dist
python -m twine check dist/*

Jaga direktori keluaran tetap kecil dan sekali pakai. Satu-satunya yang layak dibawa serta adalah berkas yang akan diterbitkan pekerjaan berikutnya, ditambah hash-nya. Sisanya, termasuk lingkungan virtual dan cache, dapat dibangun ulang dari revisi kode sumber yang tercatat. Artefak yang ramping juga lebih mudah ditinjau, karena setiap berkas di dalamnya adalah berkas yang bisa diperiksa orang.

Catat apa yang menghasilkannya: nama dan versi paket dari nama berkas, revisi kode sumber, dan eksekusi workflow yang membuatnya. Untaian versi saja tidak mengidentifikasi berkas, karena versi yang sama bisa dibangun dua kali dari commit berbeda. Tulis revisi di samping nama berkas dalam deskripsi artefak, dan perlakukan catatan itu sebagai bagian dari serah terima.

Pindahkan bita, bukan instruksi untuk membangun ulang

Build kedua adalah produk kedua. Stempel waktu, dependensi yang dibundel, dan versi alat semuanya bisa mengubah bita, jadi pembangunan ulang memerlukan bukti uji dan tinjauannya sendiri. Naikkan berkas yang sudah ditinjau, bukan membangun ulang.

Unggah berkas distribusi ke penyimpanan artefak yang disediakan platform CI Anda, dan beri pekerjaan internal rujukan ke artefak spesifik itu, bukan nama cabang.

sha256sum dist/*.whl dist/*.tar.gz
# keep the digests beside the run id in the artifact description

Jika platform Anda mendukung asal usul bertanda tangan, minta ia mengesahkan artefak dan kelak memverifikasi repositori, workflow, dan revisi kode sumber yang diharapkan. Dokumentasi pengesahan GitHub menjabarkan klaim berbentuk itu. Tanda tangan yang sah adalah bukti asal usul, bukan pemindaian kerentanan dan bukan keputusan otorisasi.

Verifikasi di dalam sebelum mengunggah

Pekerjaan internal dimulai dengan memeriksa bahwa berkas yang diterima adalah berkas yang disetujui. Bandingkan digest dengan catatan dari pekerjaan build, bukan dengan nilai yang dihitung ulang dari apa pun yang tiba.

sha256sum -c digests.txt
python -m twine check dist/*

Lalu baca metadata. Nama paket, versi, dan dependensi yang dinyatakan harus cocok dengan tinjauan yang Anda setujui. Wheel yang namanya tampak benar tetapi pin dependensinya berubah adalah paket lain yang memakai label sama. Jika metadata bergeser, perlakukan artefak sebagai tidak disetujui dan cari tahu build mana yang menghasilkannya.

Jika digest tidak cocok, berhenti. Jangan unggah, dan jangan perbaiki berkas dengan membangunnya ulang di tempat; itu menghapus bukti bahwa ada yang berubah dalam perjalanan. Ketidakcocokan berarti penyimpanan artefak, langkah unduh, atau catatannya salah, dan masing-masing pantas dijelaskan sebelum rilis diterbitkan.

Tangani jawaban versi duplikat

Repositori privat biasanya menolak menimpa versi yang sudah ada, dan penolakan itu adalah fitur. Bila unggahan gagal karena versi sudah ada, periksa catatan repositori untuk versi itu dan bandingkan berkas yang disimpannya dengan digest yang ingin Anda terbitkan.

Versi yang sudah ada bisa berarti unggahan sebelumnya berhasil dan responsnya hilang, atau bisa berarti seseorang menerbitkan konten berbeda dengan nomor yang sama.

Jangan hapus versinya, dan jangan mengarang nomor baru untuk melewati galat. Putuskan bersama pemilik rilis apakah konten tersimpan dapat diterima, lalu catat hasilnya. Jika kontennya berbeda, Anda punya masalah versi, bukan masalah pipeline.

Simpan kredensial unggah di satu sisi

Hanya penerbit internal yang memerlukan kredensial repositori, dan hanya selama unggahan berlangsung. Batasi token ke repositori tujuan dan ke operasi unggah, simpan di penyimpanan rahasia sistem internal, dan jauhkan sepenuhnya dari pekerjaan build. Jika pekerjaan build dapat menerbitkan, maka siapa pun yang dapat mengubah build dapat menerbitkan.

Batasi juga workflow internal mana yang boleh memulai penerbit. Pemicu manual dengan persetujuan wajib adalah default yang wajar untuk rilis; push ke sembarang cabang bukan.

Rilis yang selesai sebaiknya meninggalkan tiga hal: berkas distribusi, digest-nya bersama revisi kode sumber, dan catatan repositori yang menunjukkan versi yang sama.