नेटवर्क के बाहर Python wheel बनाएँ, अंदर प्रकाशित करें

आपके पास पहले से एक बिल्ड जॉब है जो wheel बनाता है, और एक निजी रिपॉज़िटरी है जिसे उसे ग्रहण करना चाहिए। गलती यह है कि दूसरी जॉब को शाखा से दोबारा बिल्ड करने दिया जाए और नतीजे को वही रिलीज़ कहा जाए। जिस फ़ाइल का परीक्षण हुआ है उसे ही आगे बढ़ाएँ, उसे डाइजेस्ट से नाम दें, और अपलोड क्रेडेंशियल अंदर ही रखें। नीचे का विवरण एक आर्टिफ़ैक्ट को सार्वजनिक CI रनर से आंतरिक प्रकाशक तक ले जाता है।

वहीं बिल्ड करें जहाँ स्रोत पहले से है

बिल्ड उसी जॉब में चलाएँ जिसके पास पहले से स्रोत, उपकरण-श्रृंखला और परीक्षण-सूट है। निजी रिपॉज़िटरी के बारे में ऐसा कुछ नहीं है जो उस जॉब से वहाँ पहुँचने की माँग करे। बिल्ड फ़्रंटएंड उसी परिवेश में स्थापित करें जो प्रोजेक्ट पहले से उपयोग करता है, फिर अगर प्रोजेक्ट दोनों वितरण प्रारूप भेजता है तो दोनों बनाएँ।

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

आउटपुट निर्देशिका छोटी और एकबारगी रखें। आगे ले जाने लायक केवल वे फ़ाइलें हैं जिन्हें अगली जॉब प्रकाशित करेगी, साथ में उनके हैश। बाकी सब कुछ, वर्चुअल परिवेश और कैश सहित, दर्ज स्रोत संशोधन से दोबारा बनाया जा सकता है। दुबला आर्टिफ़ैक्ट समीक्षा करने में भी आसान होता है, क्योंकि उसकी हर फ़ाइल ऐसी फ़ाइल है जिसे कोई जाँच सकता है।

दर्ज करें कि उन्हें किसने बनाया: फ़ाइल नामों से पैकेज का नाम और संस्करण, स्रोत संशोधन, और वह वर्कफ़्लो रन जिसने उन्हें बनाया। केवल संस्करण-स्ट्रिंग किसी फ़ाइल की पहचान नहीं करती, क्योंकि वही संस्करण अलग-अलग commit से दो बार बनाया जा सकता है। आर्टिफ़ैक्ट विवरण में फ़ाइल नामों के बगल में संशोधन लिखें, और उस रिकॉर्ड को हस्तांतरण का हिस्सा मानें।

बाइट आगे बढ़ाएँ, दोबारा बिल्ड के निर्देश नहीं

दूसरा बिल्ड दूसरा उत्पाद है। टाइमस्टैम्प, बंडल की गई निर्भरताएँ और उपकरण संस्करण सभी बाइट बदल सकते हैं, इसलिए दोबारा बिल्ड को अपने परीक्षण-प्रमाण और अपनी समीक्षा चाहिए। इसके बजाय समीक्षा की गई फ़ाइलें ही आगे बढ़ाएँ।

वितरण फ़ाइलें अपने 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 का नाम सही दिखता है पर निर्भरता-पिन बदल गए हैं, वह उसी लेबल वाला दूसरा पैकेज है। अगर मेटाडेटा खिसक गया है, तो आर्टिफ़ैक्ट को अस्वीकृत मानें और पता लगाएँ कि किस बिल्ड ने उसे बनाया।

अगर डाइजेस्ट मेल नहीं खाते, तो रुकें। अपलोड न करें, और फ़ाइल को उसी जगह दोबारा बिल्ड करके ठीक न करें; इससे यह प्रमाण मिट जाता है कि पारगमन में कुछ बदला। बेमेल का अर्थ है कि आर्टिफ़ैक्ट स्टोर, डाउनलोड चरण या रिकॉर्ड गलत है, और रिलीज़ प्रकाशित होने से पहले इनमें से हर एक का स्पष्टीकरण ज़रूरी है।

दोहरे संस्करण के उत्तर को संभालें

निजी रिपॉज़िटरी आमतौर पर मौजूदा संस्करण को अधिलेखित करने से इनकार करती हैं, और वह इनकार एक विशेषता है। जब संस्करण मौजूद होने के कारण अपलोड विफल हो, तो उस संस्करण के लिए रिपॉज़िटरी का रिकॉर्ड देखें और उसमें रखी फ़ाइलों की तुलना उन डाइजेस्ट से करें जिन्हें आप प्रकाशित करना चाहते थे।

मौजूदा संस्करण का अर्थ यह हो सकता है कि पिछला अपलोड सफल हुआ और उत्तर खो गया, या किसी ने उसी संख्या के नीचे अलग सामग्री प्रकाशित की।

संस्करण को न हटाएँ, और त्रुटि से बचने के लिए नई संख्या न गढ़ें। रिलीज़ के मालिक के साथ तय करें कि संग्रहित सामग्री स्वीकार्य है या नहीं, फिर परिणाम दर्ज करें। अगर सामग्री अलग है, तो यह संस्करणन की समस्या है, पाइपलाइन की नहीं।

अपलोड क्रेडेंशियल एक ही ओर रखें

रिपॉज़िटरी क्रेडेंशियल केवल आंतरिक प्रकाशक को चाहिए, और वह भी अपलोड की अवधि भर। टोकन को लक्ष्य रिपॉज़िटरी और अपलोड क्रियाओं तक सीमित रखें, उसे आंतरिक सिस्टम के सीक्रेट स्टोर में रखें, और बिल्ड जॉब से पूरी तरह बाहर रखें। अगर बिल्ड जॉब प्रकाशित कर सकती है, तो जो भी बिल्ड बदल सकता है वह प्रकाशित भी कर सकता है।

यह भी सीमित करें कि कौन से आंतरिक वर्कफ़्लो प्रकाशक शुरू कर सकते हैं। अनिवार्य स्वीकृति वाला मैनुअल ट्रिगर रिलीज़ के लिए उचित डिफ़ॉल्ट है; किसी भी शाखा में push नहीं।

पूर्ण रिलीज़ को तीन चीज़ें पीछे छोड़नी चाहिए: वितरण फ़ाइलें, स्रोत संशोधन के साथ उनके डाइजेस्ट, और एक रिपॉज़िटरी रिकॉर्ड जो वही संस्करण दिखाता है।