Създайте Python wheel извън мрежата и го публикувайте отвътре

Вече имате задача за изграждане, която произвежда wheel, и частно хранилище, което трябва да го получи. Грешката е да оставите втора задача да преизгради от клон и да наречете резултата същото издание. Преместете файла, който е бил тестван, наречете го по дайджест и задръжте идентификационните данни за качване отвътре. Разходката по-долу проследява един артефакт от публичен CI runner до вътрешен издател.

Изграждайте там, където вече е изходният код

Изпълнете изграждането в задачата, която вече разполага с изходния код, инструментите и набора от тестове. Нищо в частното хранилище не изисква тази задача да го достига. Инсталирайте frontend за изграждане в средата, която проектът вече използва, после създайте и двата формата за разпространение, ако проектът доставя и двата.

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

Пазете изходната директория малка и за еднократна употреба. Единственото, което си струва да се пренесе, са файловете, които следващата задача ще публикува, плюс техните хешове. Всичко останало, включително виртуални среди и кешове, може да се преизгради от записаната ревизия на изходния код. Стегнатият артефакт е и по-лесен за преглед, защото всеки файл в него е файл, който някой може да инспектира.

Запишете какво ги е произвело: името на пакета и версията от имената на файловете, ревизията на изходния код и изпълнението на работния процес, което ги е създало. Само низът за версия не идентифицира файл, защото една и съща версия може да бъде изградена два пъти от различни комити. Напишете ревизията до имената на файловете в описанието на артефакта и третирайте този запис като част от предаването.

Преместете байтове, не инструкции за преизграждане

Второто изграждане е втори продукт. Времевите отпечатъци, вградените зависимости и версиите на инструментите могат да променят байтовете, затова преизграждането се нуждае от собствени доказателства от тестове и собствен преглед. Вместо това промотирайте прегледаните файлове.

Качете файловете за разпространение в хранилището за артефакти, което предоставя вашата CI платформа, и дайте на вътрешната задача препратка към точно този артефакт, а не към име на клон.

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

Ако платформата ви поддържа подписан произход, помолете я да засвидетелства артефакта и по-късно да провери очакваното хранилище, работен процес и ревизия на изходния код. Документацията на GitHub за атестации описва твърдения от този вид. Валидният подпис е доказателство за произход, не сканиране за уязвимости и не решение за оторизация.

Проверете отвътре, преди да качвате

Вътрешната задача започва с проверка, че полученият файл е файлът, който е бил одобрен. Сравнете дайджестите със записа от задачата за изграждане, а не със стойност, преизчислена от това, което е пристигнало.

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

След това прочетете метаданните. Името на пакета, версията и декларираните зависимости трябва да съответстват на прегледа, който сте одобрили. Wheel, чието име изглежда правилно, но фиксациите на зависимостите са се променили, е друг пакет с етикета на същия. Ако метаданните са се променили, третирайте артефакта като неодобрен и разберете кое изграждане го е произвело.

Ако дайджестите не съвпадат, спрете. Не качвайте и не поправяйте файла, като го преизграждате на място; това заличава доказателството, че нещо се е променило при преноса. Несъответствието означава, че хранилището за артефакти, стъпката за изтегляне или записът са грешни и всяко от тях заслужава обяснение, преди издание да бъде публикувано.

Решете отговора за дублирана версия

Частните хранилища обикновено отказват да презапишат съществуваща версия и този отказ е функция. Когато качването се провали, защото версията съществува, прегледайте записа на хранилището за тази версия и сравнете файловете, които то пази, с дайджестите, които сте възнамерявали да публикувате.

Съществуваща версия може да означава, че предишно качване е успяло и отговорът е бил загубен, или че някой е публикувал различно съдържание под същия номер.

Не изтривайте версията и не измисляйте нов номер, за да заобиколите грешката. Решете със собственика на изданието дали съхраненото съдържание е приемливо, после запишете резултата. Ако съдържанието се различава, имате проблем с версионирането, а не проблем с pipeline-а.

Дръжте идентификационните данни за качване от една страна

Само вътрешният издател се нуждае от идентификационни данни за хранилището и то само за времетраенето на качването. Ограничете токена до целевото хранилище и до операции по качване, пазете го в хранилището за тайни на вътрешната система и го оставете напълно извън задачата за изграждане. Ако задачата за изграждане може да публикува, тогава всеки, който може да промени изграждането, може да публикува.

Ограничете и кои вътрешни работни процеси могат да стартират издателя. Ръчен тригер със задължително одобрение е разумна настройка по подразбиране за издания; push към произволен клон не е.

Завършеното издание трябва да остави три неща след себе си: файловете за разпространение, техните дайджести с ревизията на изходния код и запис в хранилището, показващ същата версия.