Python wheel ஐ வலையமைப்புக்கு வெளியே உருவாக்கி உள்ளே வெளியிடுங்கள்

wheel ஐ உருவாக்கும் build பணி ஒன்றும், அதைப் பெற வேண்டிய தனியார் களஞ்சியமும் ஏற்கனவே உங்களிடம் உள்ளன. ஒரு கிளையிலிருந்து மற்றொரு பணி மீண்டும் கட்டி, அதன் விளைவையே அதே வெளியீடு என்று அழைப்பதே தவறு. சோதிக்கப்பட்ட கோப்பையே நகர்த்துங்கள், அதை டைஜெஸ்ட்டால் பெயரிடுங்கள், பதிவேற்றச் சான்றுகளை உள்ளேயே வைத்திருங்கள். கீழே உள்ள வழிகாட்டி ஒரு artifact ஐ பொது CI runner இலிருந்து உள் வெளியீட்டாளர் வரை பின்தொடர்கிறது.

மூலம் ஏற்கனவே உள்ள இடத்தில் கட்டுங்கள்

மூலம், கருவித்தொகுப்பு, சோதனைத் தொகுப்பு ஆகியவை ஏற்கனவே உள்ள பணியிலேயே build ஐ இயக்குங்கள். தனியார் களஞ்சியத்திற்கு அந்தப் பணி சென்றடைய வேண்டும் என்பது அவசியமில்லை. திட்டம் ஏற்கனவே பயன்படுத்தும் சூழலில் build frontend ஐ நிறுவி, திட்டம் இரண்டையும் வழங்கினால் இரு விநியோக வடிவங்களையும் உருவாக்குங்கள்.

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

வெளியீட்டு அடைவைச் சிறியதாகவும் ஒரு முறை பயன்பாட்டுக்கும் உரியதாகவும் வைத்திருங்கள். அடுத்த பணி வெளியிடப்போகும் கோப்புகளும் அவற்றின் ஹாஷ்களுமே முன்னால் எடுத்துச் செல்லத் தகுந்தவை. மெய்நிகர் சூழல்கள், தற்காலிகச் சேமிப்பு உட்பட மற்ற அனைத்தையும் பதிவு செய்யப்பட்ட மூலத் திருத்தத்திலிருந்து மீண்டும் கட்டலாம். மெலிந்த artifact ஒன்றை மதிப்பாய்வு செய்வதும் எளிது, ஏனெனில் அதிலுள்ள ஒவ்வொரு கோப்பும் யாராவது பரிசோதிக்கக்கூடிய கோப்பாகும்.

அவற்றை உருவாக்கியதைப் பதிவு செய்யுங்கள்: கோப்புப் பெயர்களிலிருந்து தொகுப்பின் பெயரும் பதிப்பும், மூலத் திருத்தம், அவற்றை உருவாக்கிய workflow இயக்கம். பதிப்பு சரம் மட்டும் ஒரு கோப்பை அடையாளம் காட்டாது, ஏனெனில் அதே பதிப்பை வெவ்வேறு commit களிலிருந்து இருமுறை கட்டலாம். artifact விவரணையில் கோப்புப் பெயர்களுக்கு அருகில் திருத்தத்தை எழுதி, அந்தப் பதிவைக் கையளிப்பின் பகுதியாகக் கருதுங்கள்.

பைட்டுகளை நகர்த்துங்கள், மீண்டும் கட்டும் வழிமுறைகளை அல்ல

இரண்டாவது build இரண்டாவது தயாரிப்பு. நேர முத்திரைகள், இணைக்கப்பட்ட சார்புகள், கருவிப் பதிப்புகள் அனைத்தும் பைட்டுகளை மாற்றலாம், எனவே மீண்டும் கட்டுதலுக்கு அதன் சொந்தச் சோதனை ஆதாரமும் சொந்த மதிப்பாய்வும் தேவை. அதற்குப் பதிலாக மதிப்பாய்வு செய்யப்பட்ட கோப்புகளை முன்னேற்றுங்கள்.

உங்கள் CI தளம் வழங்கும் artifact சேமிப்பகத்திற்கு விநியோகக் கோப்புகளைப் பதிவேற்றி, உள் பணிக்கு கிளைப் பெயருக்குப் பதிலாக அந்தக் குறிப்பிட்ட artifact இன் குறிப்பைக் கொடுங்கள்.

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

உங்கள் தளம் கையொப்பமிட்ட மூலத்தை ஆதரித்தால், artifact ஐச் சான்றளிக்கச் சொல்லி, பின்னர் எதிர்பார்க்கப்பட்ட களஞ்சியம், workflow, மூலத் திருத்தம் ஆகியவற்றைச் சரிபாருங்கள். GitHub இன் சான்றளிப்பு ஆவணம் அந்த வடிவத்தின் கூற்றுகளை விவரிக்கிறது. செல்லுபடியான கையொப்பம் மூலத்திற்கான ஆதாரம், பாதிப்பு ஸ்கேன் அல்ல, அனுமதி முடிவும் அல்ல.

பதிவேற்றும் முன் உள்ளே சரிபாருங்கள்

உள் பணி தொடங்குவது, பெற்ற கோப்பு அனுமதிக்கப்பட்ட கோப்புதான் என்பதைச் சரிபார்ப்பதிலிருந்துதான். டைஜெஸ்ட்களை build பணியின் பதிவோடு ஒப்பிடுங்கள், வந்ததிலிருந்து மீண்டும் கணக்கிட்ட மதிப்போடு அல்ல.

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

பின்னர் metadata வைப் படியுங்கள். தொகுப்பின் பெயர், பதிப்பு, அறிவிக்கப்பட்ட சார்புகள் நீங்கள் அனுமதித்த மதிப்பாய்வோடு பொருந்த வேண்டும். பெயர் சரியாகத் தெரியும் ஆனால் சார்புப் பின்கள் மாறிய wheel வேறு தொகுப்பு அதே லேபிளைத் தாங்குகிறது. metadata நகர்ந்திருந்தால், artifact ஐ அனுமதிக்கப்படாததாகக் கருதி எந்த build அதை உருவாக்கியது என்பதைக் கண்டறியுங்கள்.

டைஜெஸ்ட்கள் பொருந்தவில்லை என்றால் நிறுத்துங்கள். பதிவேற்ற வேண்டாம், கோப்பை அதே இடத்தில் மீண்டும் கட்டி சரிசெய்ய வேண்டாம்; அது வழியில் ஏதோ மாறியதற்கான ஆதாரத்தை அழிக்கிறது. பொருந்தாமை என்பது artifact சேமிப்பகம், பதிவிறக்கப் படி அல்லது பதிவு தவறு என்பதாகும், ஒவ்வொன்றும் வெளியீடு வெளியிடப்படும் முன் விளக்கம் பெறத் தகுந்தது.

நகல் பதிப்பு பதிலைக் கையாளுங்கள்

தனியார் களஞ்சியங்கள் பொதுவாக ஏற்கனவே உள்ள பதிப்பை மேலெழுத மறுக்கின்றன, அந்த மறுப்பு ஒரு சிறப்பம்சம். பதிப்பு உள்ளதால் பதிவேற்றம் தோல்வியடையும்போது, அந்தப் பதிப்பிற்கான களஞ்சியப் பதிவைப் பரிசோதித்து, அது வைத்திருக்கும் கோப்புகளை நீங்கள் வெளியிட நினைத்த டைஜெஸ்ட்களோடு ஒப்பிடுங்கள்.

ஏற்கனவே உள்ள பதிப்பு என்பது முந்தைய பதிவேற்றம் வெற்றியடைந்து பதில் தொலைந்தது என்பதாகவோ, அல்லது யாரோ அதே எண்ணின் கீழ் வேறு உள்ளடக்கத்தை வெளியிட்டது என்பதாகவோ இருக்கலாம்.

பதிப்பை நீக்க வேண்டாம், பிழையைத் தாண்ட ஒரு புதிய எண்ணைக் கற்பனை செய்ய வேண்டாம். சேமிக்கப்பட்ட உள்ளடக்கம் ஏற்கத்தக்கதா என்பதை வெளியீட்டு உரிமையாளரோடு முடிவு செய்து, பின்னர் முடிவைப் பதிவு செய்யுங்கள். உள்ளடக்கம் வேறுபட்டால், உங்களுக்குப் பதிப்பு சிக்கல் உள்ளது, pipeline சிக்கல் அல்ல.

பதிவேற்றச் சான்றை ஒரு பக்கத்தில் வைத்திருங்கள்

களஞ்சியச் சான்றுகள் உள் வெளியீட்டாளருக்கு மட்டுமே தேவை, பதிவேற்றக் காலம் முழுவதும் மட்டுமே. token ஐ இலக்கு களஞ்சியத்திற்கும் பதிவேற்றச் செயல்பாடுகளுக்கும் மட்டுப்படுத்தி, உள் அமைப்பின் ரகசியச் சேமிப்பகத்தில் வைத்து, build பணியிலிருந்து முழுவதுமாக விலக்குங்கள். build பணி வெளியிட முடிந்தால், build ஐ மாற்றக்கூடிய எவரும் வெளியிட முடியும்.

எந்த உள் workflow கள் வெளியீட்டாளரைத் தொடங்கலாம் என்பதையும் கட்டுப்படுத்துங்கள். கட்டாய அனுமதியுடன் கூடிய கைமுறை தூண்டல் வெளியீடுகளுக்கு நியாயமான இயல்புநிலை; எந்தக் கிளைக்கும் push அல்ல.

முடிந்த வெளியீடு மூன்று விஷயங்களை விட்டுச் செல்ல வேண்டும்: விநியோகக் கோப்புகள், மூலத் திருத்தத்தோடு கூடிய அவற்றின் டைஜெஸ்ட்கள், அதே பதிப்பைக் காட்டும் களஞ்சியப் பதிவு.