Збірайце Python wheel па-за сеткай, публікуйце яго ўнутры

У вас ужо ёсць зборка, якая стварае wheel, і прыватны рэпазіторый, які павінен яго атрымаць. Памылка — дазволіць другой зборцы перасабраць з галіны і назваць вынік тым жа выпускам. Перанясіце файл, які прайшоў тэставанне, назвіце яго па дайджэсце і трымайце ўліковыя даныя для загрузкі ўнутры. Ніжэй разглядаецца адзін артэфакт ад публічнага CI-ранэра да ўнутранага публікатара.

Збірайце там, дзе ўжо ляжыць зыходны код

Выконвайце зборку ў задачы, якая ўжо мае зыходны код, інструменты і набор тэстаў. Нішто ў прыватным рэпазіторыі не патрабуе, каб гэтая задача да яго дабралася. Усталюйце фронтэнд зборкі ў асяроддзі, якое праект ужо выкарыстоўвае, затым стварыце абодва фарматы распаўсюджвання, калі праект пастаўляе абодва.

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, чыё імя выглядае правільным, але замацаванні залежнасцей змяніліся, — гэта іншы пакет з той жа этыкеткай. Калі метаданыя зрушыліся, лічыце артэфакт няўхваленым і высветліце, якая зборка яго стварыла.

Калі дайджэсты не супадаюць, спыніцеся. Не загружайце і не рамантуйце файл перазборкай на месцы; гэта сцірае доказ таго, што нешта змянілася ў шляху. Нясупадзенне азначае, што сховішча артэфактаў, крок загрузкі або запіс памылковыя, і кожнае з гэтага заслугоўвае тлумачэння перад публікацыяй выпуску.

Разбярыцеся з адказам пра дубль версіі

Прыватныя рэпазіторыі звычайна адмаўляюцца перазапісваць існуючую версію, і гэтая адмова — асаблівасць. Калі загрузка не ўдалася, бо версія існуе, агледзьце запіс рэпазіторыя для гэтай версіі і параўнайце файлы, якія ён захоўвае, з дайджэстамі, якія вы збіраліся апублікаваць.

Існуючая версія можа азначаць, што папярэдняя загрузка ўдалася, а адказ згубіўся, або што нехта апублікаваў іншы змест пад тым жа нумарам.

Не выдаляйце версію і не выдумляйце новы нумар, каб абысці памылку. Разам з уладальнікам выпуску вырашыце, ці прымальны захаваны змест, і запішыце вынік. Калі змест іншы, у вас праблема версіявання, а не праблема канвеера.

Трымайце ўліковыя даныя для загрузкі на адным баку

Уліковыя даныя рэпазіторыя патрэбныя толькі ўнутранаму публікатару і толькі на час загрузкі. Абмяжуйце токен мэтавым рэпазіторыем і аперацыямі загрузкі, захоўвайце яго ў сховішчы сакрэтаў унутранай сістэмы і цалкам трымайце па-за задачай зборкі. Калі задача зборкі можа публікаваць, то любы, хто можа змяніць зборку, можа публікаваць.

Абмяжуйце таксама тое, якія ўнутраныя працоўныя працэсы могуць запускаць публікатар. Ручны запуск з абавязковым ухваленнем — разумная першасная налада для выпускаў; пуш у любую галіну — не.

Завершаны выпуск павінен пакінуць пасля сябе тры рэчы: файлы распаўсюджвання, іх дайджэсты разам з рэвізіяй зыходнага коду і запіс рэпазіторыя, які паказвае тую ж версію.