Sestavte Python wheel mimo síť a publikujte ho uvnitř

Už máte úlohu sestavení, která vytváří wheel, a soukromé úložiště, které ho má přijmout. Chyba je nechat druhou úlohu znovu sestavit z větve a nazvat výsledek stejným vydáním. Přeneste soubor, který prošel testy, pojmenujte ho podle otisku a přihlašovací údaj pro nahrání držte uvnitř. Níže uvedený postup sleduje jeden artefakt od veřejného CI runneru k internímu vydavateli.

Sestavujte tam, kde už je zdrojový kód

Spusťte sestavení v úloze, která už má zdrojový kód, nástroje i testovací sadu. Nic na soukromém úložišti nevyžaduje, aby se k němu ta úloha dostala. Nainstalujte frontend sestavení v prostředí, které projekt už používá, a pak vytvořte oba distribuční formáty, pokud projekt dodává oba.

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

Výstupní adresář držte malý a jednorázový. Předávat se vyplatí jen soubory, které bude publikovat další úloha, a jejich hashe. Všechno ostatní, včetně virtuálních prostředí a cache, lze znovu sestavit ze zaznamenané revize zdrojového kódu. Hubený artefakt se také snáze kontroluje, protože každý soubor v něm je soubor, který někdo může prohlédnout.

Zaznamenejte, co je vytvořilo: název balíčku a verzi z názvů souborů, revizi zdrojového kódu a běh pracovního postupu, který je vytvořil. Samotný řetězec verze soubor neidentifikuje, protože stejnou verzi lze sestavit dvakrát z různých commitů. Napište revizi vedle názvů souborů do popisu artefaktu a berte ten záznam jako součást předání.

Přesouvejte bajty, ne pokyny k novému sestavení

Druhé sestavení je druhý produkt. Časová razítka, zabalené závislosti i verze nástrojů mohou bajty změnit, takže nové sestavení potřebuje vlastní důkazy z testů a vlastní kontrolu. Povyšujte místo toho zkontrolované soubory.

Nahrajte distribuční soubory do úložiště artefaktů, které poskytuje vaše CI platforma, a dejte interní úloze odkaz na tento konkrétní artefakt, ne na název větve.

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

Pokud vaše platforma podporuje podepsaný původ, požádejte ji o atestaci artefaktu a později o ověření očekávaného úložiště, pracovního postupu a revize zdrojového kódu. Dokumentace GitHubu k atestacím popisuje tvrzení tohoto tvaru. Platný podpis je důkaz původu, ne skenování zranitelností a ne rozhodnutí o autorizaci.

Před nahráním ověřte uvnitř

Interní úloha začíná kontrolou, že soubor, který obdržela, je soubor, který byl schválen. Porovnejte otisky se záznamem z úlohy sestavení, ne s hodnotou přepočítanou z toho, co dorazilo.

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

Pak si přečtěte metadata. Název balíčku, verze a deklarované závislosti by měly odpovídat kontrole, kterou jste schválili. Wheel, jehož název vypadá správně, ale jehož připnutí závislostí se změnila, je jiný balíček se stejnou etiketou. Pokud se metadata pohnula, berte artefakt jako neschválený a zjistěte, které sestavení ho vytvořilo.

Pokud se otisky neshodují, zastavte se. Nenahrávejte a neopravujte soubor tím, že ho na místě znovu sestavíte; to maže důkaz, že se něco při přenosu změnilo. Neshoda znamená, že úložiště artefaktů, krok stažení nebo záznam jsou špatně, a každé z toho si před publikací vydání zaslouží vysvětlení.

Vyřešte odpověď o duplicitní verzi

Soukromá úložiště obvykle odmítají přepsat existující verzi a to odmítnutí je vlastnost. Když nahrání selže, protože verze existuje, prohlédněte záznam úložiště pro tuto verzi a porovnejte soubory, které drží, s otisky, které jste chtěli publikovat.

Existující verze může znamenat, že dřívější nahrání uspělo a odpověď se ztratila, nebo že někdo publikoval jiný obsah pod stejným číslem.

Verzi nemažte a nevymýšlejte nové číslo, abyste chybu obešli. S vlastníkem vydání rozhodněte, zda je uložený obsah přijatelný, a výsledek zaznamenejte. Pokud se obsah liší, máte problém s verzováním, ne problém s pipeline.

Držte přihlašovací údaj pro nahrání na jedné straně

Přihlašovací údaje k úložišti potřebuje jen interní vydavatel, a to jen po dobu nahrávání. Omezte token na cílové úložiště a na operace nahrávání, uložte ho do trezoru tajemství interního systému a nechte ho zcela mimo úlohu sestavení. Pokud úloha sestavení může publikovat, pak publikovat může kdokoli, kdo může změnit sestavení.

Omezte také, které interní pracovní postupy mohou vydavatele spustit. Ruční spouštěč s povinným schválením je rozumné výchozí nastavení pro vydání; push do libovolné větve ne.

Hotové vydání by mělo zanechat tři věci: distribuční soubory, jejich otisky spolu s revizí zdrojového kódu a záznam úložiště ukazující stejnou verzi.