Zostavte Python wheel mimo siete a publikujte ho vnútri

Už máte build job, ktorý vytvára wheel, a súkromné úložisko, ktoré ho má prijať. Chybou je nechať druhý job znova zostaviť z vetvy a výsledok nazvať tým istým vydaním. Presuňte súbor, ktorý bol otestovaný, pomenujte ho podľa digestu a prihlasovacie údaje na nahranie držte vnútri. Nasledujúci postup sleduje jeden artefakt z verejného CI runnera k internému vydavateľovi.

Zostavujte tam, kde už zdrojový kód žije

Spustite build v jobe, ktorý už má zdrojový kód, nástroje aj testovaciu sadu. Nič na súkromnom úložisku nevyžaduje, aby k nemu tento job dosiahol. Nainštalujte build frontend v prostredí, ktoré projekt už používa, a potom vytvorte oba distribučné formáty, ak projekt dodáva oba.

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

Výstupný adresár držte malý a jednorazový. Jediné, čo sa oplatí preniesť ďalej, sú súbory, ktoré publikuje nasledujúci job, plus ich hashe. Všetko ostatné, vrátane virtuálnych prostredí a kešov, sa dá obnoviť zo zaznamenanej revízie zdroja. Štíhly artefakt sa aj ľahšie kontroluje, pretože každý súbor v ňom je súbor, ktorý si niekto môže prezrieť.

Zaznamenajte, čo ich vytvorilo: názov balíka a verziu z názvov súborov, revíziu zdroja a spustenie workflow, ktoré ich vytvorilo. Samotný reťazec verzie súbor neidentifikuje, pretože tú istú verziu možno zostaviť dvakrát z rôznych commitov. Zapíšte revíziu vedľa názvov súborov v popise artefaktu a berte tento záznam ako súčasť odovzdania.

Presúvajte bajty, nie pokyny na opätovné zostavenie

Druhý build je druhý produkt. Časové značky, pribalené závislosti a verzie nástrojov môžu zmeniť bajty, takže opätovné zostavenie potrebuje vlastné testovacie dôkazy a vlastnú kontrolu. Namiesto toho povýšte skontrolované súbory.

Nahrajte distribučné súbory do úložiska artefaktov, ktoré poskytuje vaša CI platforma, a internému jobu dajte odkaz na tento konkrétny artefakt, nie na názov vetvy.

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

Ak vaša platforma podporuje podpísaný pôvod, požiadajte ju o overenie artefaktu a neskôr skontrolujte očakávané úložisko, workflow a revíziu zdroja. GitHub dokumentácia o atestáciách opisuje tvrdenia tohto tvaru. Platný podpis je dôkazom pôvodu, nie skenovaním zraniteľností a nie rozhodnutím o autorizácii.

Pred nahratím overte vnútri

Interný job začína kontrolou, či prijatý súbor je súbor, ktorý bol schválený. Porovnajte digesty so záznamom z build jobu, nie s hodnotou prepočítanou z toho, čo prišlo.

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

Potom prečítajte metadáta. Názov balíka, verzia a deklarované závislosti by mali zodpovedať kontrole, ktorú ste schválili. Wheel, ktorého názov vyzerá správne, ale ktorého pripnutia závislostí sa zmenili, je iný balík s tou istou etiketou. Ak sa metadáta pohli, berte artefakt ako neschválený a zistite, ktorý build ho vytvoril.

Ak digesty nesedia, zastavte sa. Nenahrávajte a neopravujte súbor opätovným zostavením na mieste; to zmaže dôkaz, že sa niečo na ceste zmenilo. Nezhoda znamená, že úložisko artefaktov, krok stiahnutia alebo záznam je nesprávny, a každé z toho si pred zverejnením vydania zaslúži vysvetlenie.

Vyriešte odpoveď o duplicitnej verzii

Súkromné úložiská zvyčajne odmietajú prepísať existujúcu verziu a toto odmietnutie je vlastnosť, nie chyba. Keď nahranie zlyhá preto, že verzia existuje, prezrite záznam úložiska pre tú verziu a porovnajte súbory, ktoré drží, s digestami, ktoré ste chceli publikovať.

Existujúca verzia môže znamenať, že skoršie nahranie uspelo a odpoveď sa stratila, alebo že niekto publikoval iný obsah pod tým istým číslom.

Verziu nemažte a nevymýšľajte nové číslo, aby ste obišli chybu. Rozhodnite s vlastníkom vydania, či je uložený obsah prijateľný, a potom výsledok zaznamenajte. Ak sa obsah líši, máte problém s verzovaním, nie problém s pipeline.

Prihlasovacie údaje na nahranie držte na jednej strane

Prihlasovacie údaje k úložisku potrebuje len interný vydavateľ, a to len na čas nahrania. Obmedzte token na cieľové úložisko a na operácie nahrania, držte ho v tajnom úložisku interného systému a nechajte ho úplne mimo build jobu. Ak build job môže publikovať, potom publikovať môže každý, kto môže zmeniť build.

Obmedzte aj to, ktoré interné workflow môžu spustiť vydavateľa. Ručný spúšťač s povinným schválením je rozumné predvolené nastavenie pre vydania; push do ľubovoľnej vetvy ním nie je.

Dokončené vydanie by malo zanechať tri veci: distribučné súbory, ich digesty s revíziou zdroja a záznam úložiska, ktorý ukazuje tú istú verziu.