Python wheel’ini tarmoq tashqarisida quring va ichkarida chop eting

Sizda allaqachon wheel ishlab chiqaradigan build vazifasi va uni qabul qilishi kerak bo‘lgan xususiy repozitoriy bor. Xato — ikkinchi vazifaga shoxobchadan qayta qurishga ruxsat berib, natijani o‘sha reliz deb atashdir. Sinovdan o‘tgan faylni o‘tkazing, uni dayjest bilan nomlang va yuklash guvohnomasini ichkarida saqlang. Quyidagi qo‘llanma bitta artefaktni ommaviy CI runnerdan ichki nashriyotchigacha kuzatadi.

Manba allaqachon turgan joyda quring

Qurishni manba, asboblar zanjiri va test to‘plami allaqachon mavjud bo‘lgan vazifada bajaring. Xususiy repozitoriy bu vazifa unga yetib borishini talab qilmaydi. Build frontendni loyiha allaqachon ishlatadigan muhitga o‘rnating, so‘ngra loyiha ikkalasini ham yetkazsa, ikkala tarqatish formatini ham ishlab chiqaring.

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

Chiqish katalogini kichik va bir martalik saqlang. Oldinga olib o‘tishga arziydigan yagona narsa — keyingi vazifa chop etadigan fayllar va ularning xeshlari. Qolgan hamma narsa, jumladan virtual muhitlar va keshlar, yozib olingan manba reviziyasidan qayta qurilishi mumkin. Yengil artefaktni ko‘rib chiqish ham osonroq, chunki undagi har bir fayl kimdir tekshira oladigan fayldir.

Ularni nima ishlab chiqarganini yozib qo‘ying: fayl nomlaridan paket nomi va versiyasi, manba reviziyasi va ularni yaratgan workflow ishga tushishi. Faqat versiya satri faylni aniqlamaydi, chunki bir xil versiyani turli commitlardan ikki marta qurish mumkin. Reviziyani artefakt tavsifida fayl nomlari yoniga yozing va bu yozuvni topshirishning bir qismi deb biling.

Baytlarni o‘tkazing, qayta qurish yo‘riqnomalarini emas

Ikkinchi build — ikkinchi mahsulot. Vaqt belgilari, biriktirilgan bog‘liqliklar va asbob versiyalari baytlarni o‘zgartirishi mumkin, shuning uchun qayta qurish o‘zining test dalillari va o‘z ko‘rib chiqishini talab qiladi. Buning o‘rniga ko‘rib chiqilgan fayllarni ilgari suring.

Tarqatish fayllarini CI platformangiz taqdim etadigan artefakt omboriga yuklang va ichki vazifaga shoxobcha nomi emas, aynan o‘sha artefaktga havola bering.

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

Agar platformangiz imzolangan kelib chiqishni qo‘llab-quvvatlasa, undan artefaktni tasdiqlashni so‘rang, keyin esa kutilgan repozitoriy, workflow va manba reviziyasini tekshiring. GitHub’ning tasdiqlash hujjati shunday shakldagi da’volarni tavsiflaydi. Haqiqiy imzo kelib chiqish dalilidir, zaiflik skaneri ham emas, ruxsat qarori ham emas.

Yuklashdan oldin ichkarida tekshiring

Ichki vazifa olingan fayl tasdiqlangan fayl ekanini tekshirishdan boshlanadi. Dayjestlarni build vazifasidagi yozuv bilan solishtiring, kelgan narsadan qayta hisoblangan qiymat bilan emas.

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

So‘ngra metama’lumotlarni o‘qing. Paket nomi, versiya va e’lon qilingan bog‘liqliklar siz tasdiqlagan ko‘rib chiqishga mos kelishi kerak. Nomi to‘g‘ri ko‘ringan, lekin bog‘liqlik qadalishlari o‘zgargan wheel — xuddi shu yorliqni ko‘targan boshqa paket. Agar metama’lumotlar siljigan bo‘lsa, artefaktni tasdiqlanmagan deb biling va uni qaysi build ishlab chiqqanini aniqlang.

Agar dayjestlar mos kelmasa, to‘xtang. Yuklamang va faylni joyida qayta qurish bilan tuzatmang; bu yo‘lda nimadir o‘zgargani haqidagi dalilni o‘chiradi. Mos kelmaslik artefakt ombori, yuklab olish bosqichi yoki yozuv noto‘g‘ri ekanini bildiradi va ularning har biri reliz chop etilishidan oldin izohga loyiq.

Takroriy versiya javobini hal qiling

Xususiy repozitoriylar odatda mavjud versiyani qayta yozishdan bosh tortadi va bu rad etish — xususiyat. Yuklash versiya mavjudligi sababli muvaffaqiyatsiz bo‘lsa, omborning o‘sha versiya uchun yozuvini ko‘rib chiqing va unda saqlanayotgan fayllarni siz chop etmoqchi bo‘lgan dayjestlar bilan solishtiring.

Mavjud versiya oldingi yuklash muvaffaqiyatli bo‘lgani va javob yo‘qolganini, yoki kimdir xuddi shu raqam ostida boshqa tarkib chop etganini bildirishi mumkin.

Versiyani o‘chirmang va xatoni chetlab o‘tish uchun yangi raqam o‘ylab topmang. Saqlangan tarkib maqbulmi yoki yo‘qmi, reliz egasi bilan birga hal qiling, so‘ngra natijani yozib qo‘ying. Agar tarkib boshqacha bo‘lsa, sizda versiyalash muammosi bor, pipeline muammosi emas.

Yuklash guvohnomasini bir tomonda saqlang

Repozitoriy guvohnomalari faqat ichki nashriyotchiga kerak va faqat yuklash davomida. Tokenni maqsadli repozitoriy va yuklash amallari bilan cheklang, ichki tizimning sirli omborida saqlang va uni build vazifasidan butunlay tashqarida qoldiring. Agar build vazifasi chop eta olsa, buildni o‘zgartira oladigan har kim ham chop eta oladi.

Qaysi ichki workflowlar nashriyotchini ishga tushirishi mumkinligini ham cheklang. Majburiy tasdiqlash bilan qo‘lda ishga tushirish relizlar uchun oqilona standart; istalgan shoxobchaga push esa emas.

Tugallangan reliz orqada uchta narsani qoldirishi kerak: tarqatish fayllari, ularning dayjestlari manba reviziyasi bilan birga, va xuddi shu versiyani ko‘rsatadigan ombor yozuvi.