Zgradite Python wheel zunaj omrežja in ga objavite znotraj

Že imate opravilo gradnje, ki ustvari wheel, in zasebno shrambo, ki naj bi ga prejela. Napaka je pustiti drugemu opravilu, da znova zgradi iz veje, in rezultat imenovati ista izdaja. Premaknite datoteko, ki je bila preizkušena, poimenujte jo po digestu in poverilnice za nalaganje obdržite znotraj. Spodnji opis spremlja en artefakt od javnega CI runnerja do notranjega izdajatelja.

Gradite tam, kjer izvorna koda že živi

Zaženite gradnjo v opravilu, ki že ima izvorno kodo, orodjarno in nabor testov. Nič pri zasebni shrambi ne zahteva, da to opravilo doseže do nje. Namestite build frontend v okolje, ki ga projekt že uporablja, nato pa ustvarite oba formata distribucije, če projekt pošilja oba.

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

Izhodno mapo ohranite majhno in za enkratno uporabo. Edino, kar je vredno prenesti naprej, so datoteke, ki jih bo objavilo naslednje opravilo, in njihove zgoščene vrednosti. Vse drugo, vključno z virtualnimi okolji in predpomnilniki, je mogoče obnoviti iz zabeležene revizije izvora. Vitki artefakt je tudi lažje pregledati, ker je vsaka datoteka v njem datoteka, ki jo lahko nekdo pregleda.

Zabeležite, kaj jih je ustvarilo: ime paketa in različico iz imen datotek, revizijo izvora in zagon workflow, ki jih je ustvaril. Sam niz različice datoteke ne identificira, ker je isto različico mogoče zgraditi dvakrat iz različnih commitov. Revizijo zapišite poleg imen datotek v opis artefakta in ta zapis obravnavajte kot del predaje.

Premikajte bajte, ne navodil za ponovno gradnjo

Druga gradnja je drug izdelek. Časovni žigi, priložene odvisnosti in različice orodij lahko spremenijo bajte, zato ponovna gradnja potrebuje svoje dokaze testov in svoj pregled. Namesto tega povišajte pregledane datoteke.

Naložite distribucijske datoteke v shrambo artefaktov, ki jo ponuja vaša CI platforma, in notranjemu opravilu dajte sklic na ta konkretni artefakt, ne na ime veje.

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

Če vaša platforma podpira podpisan izvor, jo prosite, da overi artefakt, pozneje pa preverite pričakovano shrambo, workflow in revizijo izvora. GitHub dokumentacija o atestacijah opisuje trditve takšne oblike. Veljaven podpis je dokaz o izvoru, ne pregled ranljivosti in ne odločitev o avtorizaciji.

Pred nalaganjem preverite znotraj

Notranje opravilo začne s preverjanjem, ali je prejeta datoteka tista datoteka, ki je bila odobrena. Primerjajte digeste z zapisom iz opravila gradnje, ne z vrednostjo, preračunano iz tega, kar je prispelo.

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

Nato preberite metapodatke. Ime paketa, različica in navedene odvisnosti se morajo ujemati s pregledom, ki ste ga odobrili. Wheel, katerega ime je videti pravilno, a so se njegove pripete odvisnosti spremenile, je drug paket z isto oznako. Če so se metapodatki premaknili, artefakt obravnavajte kot neodobren in ugotovite, katera gradnja ga je ustvarila.

Če se digesti ne ujemajo, se ustavite. Ne nalagajte in datoteke ne popravljajte s ponovno gradnjo na mestu; to izbriše dokaz, da se je nekaj na poti spremenilo. Neujemanje pomeni, da so shramba artefaktov, korak prenosa ali zapis napačni, in vsak od teh si zasluži razlago, preden je izdaja objavljena.

Obravnavajte odgovor o podvojeni različici

Zasebne shrambe običajno zavrnejo prepis obstoječe različice in ta zavrnitev je lastnost. Ko nalaganje ne uspe, ker različica obstaja, pregledajte zapis shrambe za to različico in primerjajte datoteke, ki jih hrani, z digesti, ki ste jih nameravali objaviti.

Obstoječa različica lahko pomeni, da je prejšnje nalaganje uspelo in se je odgovor izgubil, ali da je nekdo objavil drugačno vsebino pod isto številko.

Različice ne izbrišite in si ne izmislite nove številke, da bi obšli napako. Odločite se z lastnikom izdaje, ali je shranjena vsebina sprejemljiva, nato izid zabeležite. Če se vsebina razlikuje, imate težavo z različicami, ne težavo s pipeline.

Poverilnice za nalaganje imejte na eni strani

Poverilnice shrambe potrebuje le notranji izdajatelj in le za čas nalaganja. Žeton omejite na ciljno shrambo in na operacije nalaganja, hranite ga v shrambi skrivnosti notranjega sistema in ga pustite popolnoma zunaj opravila gradnje. Če lahko opravilo gradnje objavlja, potem lahko objavlja vsak, ki lahko spremeni gradnjo.

Omejite tudi, kateri notranji workflow lahko zaženejo izdajatelja. Ročni sprožilec z obvezno odobritvijo je razumna privzeta izbira za izdaje; push v katero koli vejo ni.

Končana izdaja naj za seboj pusti tri stvari: distribucijske datoteke, njihove digeste z revizijo izvora in zapis shrambe, ki kaže isto različico.