Python wheel نیٹ ورک سے باہر بنائیں اور اندر شائع کریں

آپ کے پاس پہلے سے ایک بلڈ جاب ہے جو wheel بناتی ہے اور ایک نجی مخزن جو اسے وصول کرنا چاہیے۔ غلطی یہ ہے کہ دوسری جاب کو کسی برانچ سے دوبارہ تعمیر کرنے دیں اور نتیجے کو وہی ریلیز کہیں۔ وہ فائل منتقل کریں جس کی جانچ ہوئی، اسے ڈائجسٹ کے نام سے موسوم کریں، اور اپ لوڈ کی اسناد اندر ہی رکھیں۔ نیچے دی گئی تفصیل ایک artefact کا سفر عوامی CI runner سے اندرونی ناشر تک بیان کرتی ہے۔

وہیں بنائیں جہاں ماخذ پہلے سے موجود ہے

بلڈ اسی جاب میں چلائیں جس کے پاس ماخذ، اوزاروں کی زنجیر اور ٹیسٹ سیٹ پہلے سے موجود ہیں۔ نجی مخزن کے لیے یہ ضروری نہیں کہ وہ جاب اس تک پہنچے۔ بلڈ فرنٹ اینڈ کو اسی ماحول میں نصب کریں جو منصوبہ پہلے سے استعمال کرتا ہے، پھر اگر منصوبہ دونوں بھیجتا ہے تو تقسیم کی دونوں صورتیں تیار کریں۔

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

آؤٹ پٹ ڈائریکٹری کو چھوٹا اور ایک بار استعمال کے قابل رکھیں۔ آگے لے جانے کے قابل صرف وہ فائلیں ہیں جو اگلی جاب شائع کرے گی، ان کے ہیش کے ساتھ۔ باقی سب کچھ، بشمول مجازی ماحول اور کیش، ریکارڈ شدہ ماخذ نظرثانی سے دوبارہ بنایا جا سکتا ہے۔ دبلا artefact جانچنے میں بھی آسان ہے، کیونکہ اس کی ہر فائل ایسی فائل ہے جسے کوئی دیکھ سکتا ہے۔

ریکارڈ کریں کہ انہیں کس نے پیدا کیا: فائل ناموں سے پیکج کا نام اور ورژن، ماخذ نظرثانی، اور وہ workflow اشتغال جس نے انہیں بنایا۔ صرف ورژن کی تار کسی فائل کی شناخت نہیں کرتی، کیونکہ وہی ورژن مختلف commit سے دو بار بنایا جا سکتا ہے۔ artefact کی تفصیل میں فائل ناموں کے ساتھ نظرثانی لکھیں اور اس ریکارڈ کو حوالگی کا حصہ سمجھیں۔

بائٹس منتقل کریں، دوبارہ تعمیر کی ہدایات نہیں

دوسری تعمیر دوسری مصنوع ہے۔ وقت کے نشان، شامل انحصار اور اوزاروں کے ورژن بائٹس بدل سکتے ہیں، اس لیے دوبارہ تعمیر کو اپنے ٹیسٹ ثبوت اور اپنی جانچ درکار ہے۔ اس کے بجائے جانچ شدہ فائلوں کو آگے بڑھائیں۔

تقسیم کی فائلیں آپ کے CI پلیٹ فارم کے فراہم کردہ artefact مخزن میں اپ لوڈ کریں، اور اندرونی جاب کو برانچ کے نام کے بجائے اسی مخصوص artefact کا حوالہ دیں۔

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

اگر آپ کا پلیٹ فارم دستخط شدہ اصل کی حمایت کرتا ہے، تو اس سے artefact کی تصدیق کروائیں اور بعد میں متوقع مخزن، workflow اور ماخذ نظرثانی کی جانچ کریں۔ GitHub کی تصدیق نامہ دستاویز ایسی ہی شکل کے دعوے بیان کرتی ہے۔ درست دستخط اصل کا ثبوت ہیں، نہ کمزوری کی جانچ اور نہ اجازت کا فیصلہ۔

اپ لوڈ سے پہلے اندر جانچ کریں

اندرونی جاب اس بات سے شروع ہوتی ہے کہ موصول ہونے والی فائل وہی ہے جو منظور ہوئی تھی۔ ڈائجسٹ کا موازنہ بلڈ جاب کے ریکارڈ سے کریں، نہ کہ جو آیا اس سے دوبارہ حساب کردہ قدر سے۔

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

پھر میٹا ڈیٹا پڑھیں۔ پیکج کا نام، ورژن اور اعلان شدہ انحصار آپ کی منظور شدہ جانچ سے مطابقت رکھنے چاہئیں۔ ایسا wheel جس کا نام درست لگتا ہے مگر انحصار کے پن بدل گئے ہیں، وہی لیبل رکھنے والا دوسرا پیکج ہے۔ اگر میٹا ڈیٹا ہل گیا ہے تو artefact کو غیر منظور شدہ سمجھیں اور معلوم کریں کہ کس تعمیر نے اسے پیدا کیا۔

اگر ڈائجسٹ مطابقت نہ رکھیں تو رک جائیں۔ اپ لوڈ نہ کریں اور فائل کو وہیں دوبارہ تعمیر کر کے ٹھیک نہ کریں؛ یہ اس ثبوت کو مٹا دیتا ہے کہ راستے میں کچھ بدلا۔ عدم مطابقت کا مطلب ہے کہ artefact مخزن، ڈاؤن لوڈ کا مرحلہ یا ریکارڈ غلط ہے، اور ان میں سے ہر ایک ریلیز شائع ہونے سے پہلے وضاحت کا مستحق ہے۔

دوہرے ورژن کے جواب سے نمٹیں

نجی مخزن عموماً موجودہ ورژن پر تحریر کرنے سے انکار کرتے ہیں، اور یہ انکار ایک خصوصیت ہے۔ جب اپ لوڈ اس لیے ناکام ہو کہ ورژن موجود ہے، تو اس ورژن کے لیے مخزن کا ریکارڈ دیکھیں اور اس میں رکھی فائلوں کا موازنہ ان ڈائجسٹ سے کریں جو آپ شائع کرنا چاہتے تھے۔

موجودہ ورژن کا مطلب یہ ہو سکتا ہے کہ پچھلا اپ لوڈ کامیاب ہوا اور جواب گم ہو گیا، یا کسی نے اسی نمبر کے تحت مختلف مواد شائع کیا۔

ورژن حذف نہ کریں، اور غلطی سے گزرنے کے لیے نیا نمبر نہ گھڑیں۔ ریلیز کے مالک کے ساتھ فیصلہ کریں کہ محفوظ مواد قابل قبول ہے یا نہیں، پھر نتیجہ ریکارڈ کریں۔ اگر مواد مختلف ہے تو آپ کے پاس ورژن بندی کا مسئلہ ہے، پائپ لائن کا مسئلہ نہیں۔

اپ لوڈ کی اسناد ایک ہی طرف رکھیں

مخزن کی اسناد صرف اندرونی ناشر کو درکار ہیں، اور صرف اپ لوڈ کی مدت تک۔ ٹوکن کو ہدف مخزن اور اپ لوڈ کارروائیوں تک محدود رکھیں، اندرونی نظام کے رازخانے میں رکھیں، اور اسے بلڈ جاب سے بالکل باہر رکھیں۔ اگر بلڈ جاب شائع کر سکتی ہے تو جو بھی بلڈ بدل سکتا ہے وہ بھی شائع کر سکتا ہے۔

یہ بھی محدود کریں کہ کون سی اندرونی workflow ناشر کو شروع کر سکتی ہیں۔ لازمی منظوری کے ساتھ دستی محرک ریلیز کے لیے معقول طے شدہ ہے؛ کسی بھی برانچ پر push نہیں۔

مکمل ریلیز کو تین چیزیں چھوڑنی چاہئیں: تقسیم کی فائلیں، ماخذ نظرثانی کے ساتھ ان کے ڈائجسٹ، اور ایک مخزن ریکارڈ جو وہی ورژن دکھائے۔