ابنِ 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 الذي يبدو اسمه صحيحًا لكن تثبيتات اعتمادياته تغيّرت هو حزمة أخرى تحمل الملصق نفسه. إن تحركت البيانات الوصفية، فاعتبر الأثر غير معتمد واكتشف أي بناء أنتجه.

إن لم تطابق البصمات، توقف. لا ترفع، ولا تصلح الملف بإعادة بنائه في مكانه؛ فذلك يمحو الدليل على أن شيئًا تغيّر أثناء النقل. عدم التطابق يعني أن مخزن الأثر أو خطوة التنزيل أو السجل خطأ، وكل واحد منها يستحق تفسيرًا قبل نشر إصدار.

تعامل مع ردّ الإصدار المكرر

ترفض المستودعات الخاصة عادةً الكتابة فوق إصدار موجود، وهذا الرفض ميزة. عندما يفشل الرفع لأن الإصدار موجود، افحص سجل المستودع لذلك الإصدار وقارن الملفات التي يحتفظ بها بالبصمات التي نويت نشرها.

الإصدار الموجود قد يعني أن رفعًا سابقًا نجح وضاع الرد، أو قد يعني أن أحدهم نشر محتوى مختلفًا تحت الرقم نفسه.

لا تحذف الإصدار، ولا تختلق رقمًا جديدًا للعبور من الخطأ. قرّر مع مالك الإصدار ما إذا كان المحتوى المخزَّن مقبولًا، ثم سجّل النتيجة. إن اختلف المحتوى، فلديك مشكلة في الإصدارات لا مشكلة في خط الأنابيب.

أبقِ اعتماد الرفع على جانب واحد

الناشر الداخلي وحده يحتاج اعتمادات المستودع، ولفترة الرفع فقط. ضيّق نطاق الرمز إلى المستودع الهدف وإلى عمليات الرفع، واحفظه في مخزن أسرار النظام الداخلي، وأبعده تمامًا عن مهمة البناء. إن استطاعت مهمة البناء النشر، فمن يستطيع تغيير البناء يستطيع النشر.

قيّد أيضًا أي سير عمل داخلي يجوز له تشغيل الناشر. مشغّل يدوي مع موافقة مطلوبة هو افتراضي معقول للإصدارات؛ أما دفعة إلى أي فرع فليست كذلك.

ينبغي أن يترك الإصدار المنتهي ثلاثة أشياء خلفه: ملفات التوزيع، وبصماتها مع مراجعة الكود، وسجل مستودع يظهر الإصدار نفسه.