नेटवर्क बाहिर 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 होइन।

सम्पन्न रिलिजले तीन कुरा पछाडि छोड्नुपर्छ: वितरण फाइल, स्रोत संशोधनसहितका तिनका डाइजेस्ट, र त्यही संस्करण देखाउने रिपोजिटरी दर्ता।