Bumuo ng Python wheel sa labas ng network at i-publish sa loob

Mayroon ka nang build job na gumagawa ng wheel at pribadong repository na dapat tumanggap nito. Ang pagkakamali ay hayaang muling buuin ng pangalawang job mula sa isang branch at tawagin ang resulta na parehong release. Ilipat ang file na sinubukan, pangalanan ito ayon sa digest, at panatilihin ang kredensyal sa pag-upload sa loob. Sinusundan ng gabay sa ibaba ang isang artifact mula sa pampublikong CI runner hanggang sa panloob na publisher.

Bumuo kung saan naroon na ang source code

Patakbuhin ang build sa job na mayroon nang source code, toolchain at test suite. Wala sa isang pribadong repository ang nangangailangan na maabot ito ng job na iyon. I-install ang build frontend sa kapaligirang ginagamit na ng proyekto, pagkatapos ay gumawa ng parehong format ng distribusyon kung ipinapadala ng proyekto ang dalawa.

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

Panatilihing maliit at isang gamitan ang output directory. Ang tanging sulit dalhin pasulong ay ang mga file na ipapublish ng susunod na job, kasama ang kanilang mga hash. Lahat ng iba, kabilang ang mga virtual environment at cache, ay maaaring buuing muli mula sa naitalang source revision. Mas madali ring suriin ang isang payat na artifact, dahil bawat file nito ay file na maaaring siyasatin ng sinuman.

Itala kung ano ang gumawa ng mga ito: ang pangalan ng package at bersyon mula sa mga pangalan ng file, ang source revision, at ang workflow run na lumikha sa kanila. Ang string ng bersyon lamang ay hindi nagbibigay ng pagkakakilanlan sa isang file, dahil ang parehong bersyon ay maaaring buuin nang dalawang beses mula sa magkaibang commit. Isulat ang revision sa tabi ng mga pangalan ng file sa paglalarawan ng artifact, at ituring ang talaang iyon na bahagi ng paghahatid.

Ilipat ang bytes, hindi ang mga tagubilin sa muling pagbuo

Ang pangalawang build ay pangalawang produkto. Ang mga timestamp, nakabundol na dependency at bersyon ng tool ay maaaring magbago ng bytes, kaya ang muling pagbuo ay nangangailangan ng sarili nitong ebidensya ng pagsubok at sariling pagsusuri. Sa halip, isulong ang mga nasuring file.

I-upload ang mga file ng distribusyon sa artifact store na ibinibigay ng iyong CI platform, at bigyan ang panloob na job ng reference sa partikular na artifact na iyon sa halip na pangalan ng branch.

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

Kung sinusuportahan ng iyong platform ang pinirmahang pinagmulan, hilingin itong patunayan ang artifact at pagkatapos ay i-verify ang inaasahang repository, workflow at source revision. Inilalarawan ng GitHub dokumentasyon ng attestation ang mga claim na ganoon ang hugis. Ang wastong pirma ay ebidensya ng pinagmulan, hindi vulnerability scan at hindi desisyon sa awtorisasyon.

I-verify sa loob bago mag-upload

Nagsisimula ang panloob na job sa pagsuri na ang natanggap na file ay ang file na inaprubahan. Ihambing ang mga digest sa tala mula sa build job, hindi sa halagang muling kinalkula mula sa dumating.

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

Pagkatapos, basahin ang metadata. Ang pangalan ng package, bersyon at mga deklaradong dependency ay dapat tumugma sa pagsusuring inaprubahan mo. Ang wheel na mukhang tama ang pangalan ngunit nagbago ang mga pin ng dependency ay ibang package na may parehong label. Kung gumalaw ang metadata, ituring na hindi aprubado ang artifact at alamin kung aling build ang gumawa nito.

Kung hindi tumutugma ang mga digest, huminto. Huwag mag-upload at huwag ayusin ang file sa pamamagitan ng muling pagbuo nito sa puwesto; binubura niyon ang ebidensya na may nagbago sa daan. Ang hindi pagtutugma ay nangangahulugang mali ang artifact store, ang hakbang ng pag-download o ang tala, at bawat isa sa mga iyon ay karapat-dapat sa paliwanag bago mailathala ang isang release.

Harapin ang sagot tungkol sa doble na bersyon

Karaniwang tumatanggi ang mga pribadong repository na i-overwrite ang umiiral na bersyon, at ang pagtangging iyon ay isang katangian. Kapag nabigo ang upload dahil mayroon nang bersyon, siyasatin ang tala ng repository para sa bersyong iyon at ihambing ang mga file na hawak nito sa mga digest na balak mong ilathala.

Ang umiiral na bersyon ay maaaring mangahulugang nagtagumpay ang naunang upload at nawala ang sagot, o may naglathala ng ibang nilalaman sa ilalim ng parehong numero.

Huwag burahin ang bersyon at huwag mag-imbento ng bagong numero para malampasan ang error. Magpasya kasama ng may-ari ng release kung katanggap-tanggap ang nakaimbak na nilalaman, pagkatapos ay itala ang kinalabasan. Kung magkaiba ang nilalaman, may problema ka sa versioning, hindi problema sa pipeline.

Panatilihin ang kredensyal sa pag-upload sa isang panig

Ang panloob na publisher lamang ang nangangailangan ng kredensyal ng repository, at habang tumatagal lamang ang pag-upload. Limitahan ang token sa target na repository at sa mga operasyon ng pag-upload, itago ito sa secret store ng panloob na sistema, at ilayo ito nang lubusan sa build job. Kung makakapaglathala ang build job, makakapaglathala ang sinumang makakapagbago ng build.

Limitahan din kung aling panloob na workflow ang maaaring magsimula ng publisher. Ang manual na trigger na may kinakailangang pag-apruba ay makatwirang default para sa mga release; ang push sa anumang branch ay hindi.

Ang natapos na release ay dapat mag-iwan ng tatlong bagay: ang mga file ng distribusyon, ang kanilang mga digest kasama ang source revision, at tala ng repository na nagpapakita ng parehong bersyon.