नेटवर्कच्या बाहेर 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 नाही.

पूर्ण झालेल्या रिलीजने तीन गोष्टी मागे ठेवल्या पाहिजेत: वितरण फाईल्स, स्रोत आवृत्तीसह त्यांचे डाइजेस्ट, आणि तीच आवृत्ती दाखवणारी रिपॉझिटरी नोंद.