Зберіть wheel Python поза мережею й опублікуйте його всередині

У вас уже є завдання збирання, яке створює wheel, і приватний репозиторій, який має його отримати. Помилка — дозволити другому завданню перезібрати все з гілки й назвати результат тим самим випуском. Переносьте файл, який пройшов перевірку, називайте його за дайджестом і тримайте облікові дані для завантаження всередині. Нижче розібрано один артефакт на шляху від публічного CI-раннера до внутрішнього публікатора.

Збирайте там, де вже лежить вихідний код

Запускайте збирання в завданні, яке вже має вихідний код, інструменти й набір тестів. Приватний репозиторій аж ніяк не вимагає, щоб це завдання мало до нього доступ. Установіть фронтенд збирання в середовище, яке проєкт уже використовує, і потім зберіть обидва формати дистрибутива, якщо проєкт постачає обидва.

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

Тримайте каталог виводу малим і одноразовим. Переносити далі варто лише файли, які опублікує наступне завдання, та їхні хеші. Усе інше, зокрема віртуальні середовища й кеші, можна відтворити із записаної ревізії вихідного коду. Компактний артефакт ще й легше переглядати, бо кожен файл у ньому — це файл, який хтось може оглянути.

Запишіть, що їх породило: назву пакета й версію з назв файлів, ревізію вихідного коду та запуск workflow, який їх створив. Сам рядок версії не ідентифікує файл, бо ту саму версію можна зібрати двічі з різних комітів. Запишіть ревізію поряд із назвами файлів в описі артефакта й вважайте цей запис частиною передачі.

Переносьте байти, а не інструкції щодо перезбирання

Друге збирання — це другий продукт. Мітки часу, включені залежності та версії інструментів можуть змінити байти, тож перезбирання потребує власних доказів тестів і власного огляду. Просувайте натомість переглянуті файли.

Завантажте файли дистрибутива до сховища артефактів, яке надає ваша CI-платформа, і дайте внутрішньому завданню посилання саме на цей артефакт, а не на назву гілки.

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

Якщо ваша платформа підтримує підписане походження, попросіть її засвідчити артефакт, а згодом перевірте очікуваний репозиторій, workflow і ревізію вихідного коду. Документація щодо атестацій GitHub описує твердження такої форми. Дійсний підпис — це свідчення походження, а не сканування вразливостей і не рішення про авторизацію.

Перевірте всередині перед завантаженням

Внутрішнє завдання починається з перевірки, що отриманий файл — це саме той файл, який було схвалено. Порівнюйте дайджести із записом із завдання збирання, а не зі значенням, перерахованим із того, що надійшло.

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

Потім прочитайте метадані. Назва пакета, версія й оголошені залежності мають збігатися з оглядом, який ви схвалили. Wheel, чия назва виглядає правильно, але чиї закріплення залежностей змінилися, — це інший пакет під тією самою міткою. Якщо метадані зсунулися, вважайте артефакт несхваленим і з'ясуйте, яке збирання його створило.

Якщо дайджести не збігаються, зупиніться. Не завантажуйте й не ремонтуйте файл, перезбираючи його на місці; це стирає свідчення того, що щось змінилося в дорозі. Незбіг означає, що сховище артефактів, крок завантаження або запис хибні, і кожне з цього варте пояснення до публікації випуску.

Розберіться з відповіддю про повторювану версію

Приватні репозиторії зазвичай відмовляються перезаписувати наявну версію, і ця відмова є властивістю. Коли завантаження не вдається через те, що версія існує, перегляньте запис репозиторію для цієї версії й порівняйте файли, які він тримає, з дайджестами, які ви мали намір опублікувати.

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

Не видаляйте версію й не вигадуйте новий номер, щоб обійти помилку. Вирішіть разом із власником випуску, чи прийнятний збережений вміст, а потім запишіть результат. Якщо вміст відрізняється, у вас проблема версіонування, а не проблема конвеєра.

Тримайте облікові дані для завантаження з одного боку

Облікові дані репозиторію потрібні лише внутрішньому публікатору і лише на час завантаження. Обмежте токен цільовим репозиторієм і операціями завантаження, тримайте його у сховищі секретів внутрішньої системи й тримайте повністю поза завданням збирання. Якщо завдання збирання може публікувати, то публікувати може кожен, хто може змінити збирання.

Обмежте також, які внутрішні workflow можуть запускати публікатор. Ручний запуск з обов'язковим схваленням — розумне типове рішення для випусків; push у будь-яку гілку — ні.

Готовий випуск має залишити три речі: файли дистрибутива, їхні дайджести разом із ревізією вихідного коду та запис репозиторію, що показує ту саму версію.