یک wheel پایتون را بیرون از شبکه بسازید و آن را درون شبکه منتشر کنید

شما از پیش یک کار ساخت دارید که wheel تولید می‌کند و یک مخزن خصوصی که باید آن را دریافت کند. اشتباه این است که بگذارید کار دومی از یک شاخه دوباره بسازد و نتیجه را همان انتشار بنامد. فایلی را که آزموده شده جابه‌جا کنید، آن را با هش نام‌گذاری کنید و اعتبارنامهٔ بارگذاری را درون نگه دارید. شرح زیر یک آرتیفکت را از یک runner عمومی CI تا یک ناشر داخلی دنبال می‌کند.

همان‌جا بسازید که کد منبع هست

ساخت را در کاری اجرا کنید که از پیش کد منبع، زنجیرهٔ ابزار و مجموعهٔ آزمون را دارد. هیچ چیز در یک مخزن خصوصی ایجاب نمی‌کند که آن کار به آن دسترسی پیدا کند. frontend ساخت را در محیطی نصب کنید که پروژه از پیش به کار می‌برد، سپس اگر پروژه هر دو قالب توزیع را عرضه می‌کند هر دو را تولید کنید.

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

پوشهٔ خروجی را کوچک و یک‌بارمصرف نگه دارید. تنها چیزی که ارزش بردن به مرحلهٔ بعد را دارد فایل‌هایی است که کار بعدی منتشر می‌کند، به‌همراه هش‌هایشان. همه‌چیز دیگر، از جمله محیط‌های مجازی و حافظه‌های نهان، را می‌توان از بازبینی ثبت‌شدهٔ کد منبع دوباره ساخت. یک آرتیفکت لاغر بازبینی‌اش هم آسان‌تر است، چون هر فایلی در آن فایلی است که کسی می‌تواند بازرسی کند.

ثبت کنید چه چیزی آن‌ها را ساخته است: نام و نسخهٔ بسته از نام فایل‌ها، بازبینی کد منبع، و اجرای workflow که آن‌ها را ساخته است. یک رشتهٔ نسخه به‌تنهایی یک فایل را شناسایی نمی‌کند، چون همان نسخه را می‌توان دو بار از commitهای متفاوت ساخت. بازبینی را کنار نام فایل‌ها در توضیح آرتیفکت بنویسید و آن ثبت را بخشی از تحویل بدانید.

بایت‌ها را جابه‌جا کنید، نه دستورهای ساخت دوباره

ساخت دوم یک محصول دوم است. برچسب‌های زمانی، وابستگی‌های بسته‌بندی‌شده و نسخه‌های ابزار همه می‌توانند بایت‌ها را تغییر دهند، پس ساخت دوباره شواهد آزمون خودش و بازبینی خودش را می‌خواهد. در عوض همان فایل‌های بازبینی‌شده را ارتقا دهید.

فایل‌های توزیع را در انبار آرتیفکتی که پلتفرم 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 که نامش درست به نظر می‌رسد اما سنجاق‌های وابستگی‌اش عوض شده، بستهٔ دیگری با همان برچسب است. اگر فراداده جابه‌جا شده، آرتیفکت را تأییدنشده بدانید و پیدا کنید کدام ساخت آن را تولید کرده است.

اگر هش‌ها نمی‌خوانند، بایستید. بارگذاری نکنید و فایل را با ساخت دوباره در همان جا ترمیم نکنید؛ این شاهد اینکه چیزی در مسیر تغییر کرده را پاک می‌کند. ناهمخوانی یعنی انبار آرتیفکت، مرحلهٔ دانلود یا ثبت اشتباه است، و هر یک از این‌ها پیش از انتشار یک نسخه سزاوار توضیح است.

پاسخ نسخهٔ تکراری را مدیریت کنید

مخزن‌های خصوصی معمولاً از بازنویسی نسخهٔ موجود سر باز می‌زنند و این خودداری یک ویژگی است. وقتی بارگذاری شکست می‌خورد چون نسخه وجود دارد، ثبت مخزن برای آن نسخه را بازرسی کنید و فایل‌هایی را که نگه می‌دارد با هش‌هایی که قصد انتشارشان را داشتید مقایسه کنید.

نسخهٔ موجود می‌تواند یعنی بارگذاری پیشین موفق بوده و پاسخ گم شده، یا یعنی کسی محتوای دیگری زیر همان شماره منتشر کرده است.

نسخه را حذف نکنید و برای عبور از خطا شمارهٔ تازه از خود نسازید. با مالک انتشار تصمیم بگیرید که محتوای ذخیره‌شده پذیرفتنی است یا نه، سپس نتیجه را ثبت کنید. اگر محتوا متفاوت است، مشکل نسخه‌بندی دارید نه مشکل pipeline.

اعتبارنامهٔ بارگذاری را یک طرف نگه دارید

فقط ناشر داخلی به اعتبارنامهٔ مخزن نیاز دارد و آن هم تنها به اندازهٔ مدت بارگذاری. توکن را به مخزن هدف و به عملیات بارگذاری محدود کنید، آن را در انبار اسرار سامانهٔ داخلی نگه دارید و کاملاً بیرون از کار ساخت بگذارید. اگر کار ساخت بتواند منتشر کند، هر کس بتواند ساخت را تغییر دهد هم می‌تواند منتشر کند.

همچنین محدود کنید کدام workflowهای داخلی اجازهٔ راه‌اندازی ناشر را دارند. یک ماشهٔ دستی با تأیید اجباری پیش‌فرض معقولی برای انتشارهاست؛ push به هر شاخه‌ای نیست.

انتشار تمام‌شده باید سه چیز بر جای بگذارد: فایل‌های توزیع، هش‌هایشان همراه با بازبینی کد منبع، و یک ثبت مخزن که همان نسخه را نشان می‌دهد.