നെറ്റ്‌വർക്കിന് പുറത്ത് Python 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 മറ്റൊരു പാക്കേജാണ്, അതേ ലേബലിൽ. മെറ്റാഡേറ്റ നീങ്ങിയെങ്കിൽ ആർട്ടിഫാക്ടിനെ അംഗീകരിക്കാത്തതായി കണക്കാക്കി ഏത് ബിൽഡ് അത് നിർമ്മിച്ചുവെന്ന് കണ്ടെത്തുക.

ഡൈജസ്റ്റുകൾ പൊരുത്തപ്പെടുന്നില്ലെങ്കിൽ നിർത്തുക. അപ്‌ലോഡ് ചെയ്യരുത്, ഫയൽ അവിടെത്തന്നെ വീണ്ടും നിർമ്മിച്ച് നന്നാക്കരുത്; അത് കൈമാറ്റത്തിൽ എന്തോ മാറിയെന്ന തെളിവ് മായ്ക്കുന്നു. പൊരുത്തക്കേട് എന്നാൽ ആർട്ടിഫാക്ട് സ്റ്റോർ, ഡൗൺലോഡ് ഘട്ടം അല്ലെങ്കിൽ രേഖ തെറ്റാണ് എന്നാണ്, റിലീസ് പ്രസിദ്ധീകരിക്കുന്നതിന് മുൻപ് അവയോരോന്നും വിശദീകരണം അർഹിക്കുന്നു.

ഇരട്ട പതിപ്പിന്റെ മറുപടി കൈകാര്യം ചെയ്യുക

സ്വകാര്യ റിപ്പോസിറ്ററികൾ സാധാരണയായി നിലവിലുള്ള ഒരു പതിപ്പ് മേലെഴുതാൻ വിസമ്മതിക്കുന്നു, ആ വിസമ്മതം ഒരു സവിശേഷതയാണ്. പതിപ്പ് ഉള്ളതിനാൽ അപ്‌ലോഡ് പരാജയപ്പെട്ടാൽ, ആ പതിപ്പിനുള്ള റിപ്പോസിറ്ററി രേഖ പരിശോധിച്ച് അതിൽ സൂക്ഷിക്കുന്ന ഫയലുകളെ നിങ്ങൾ പ്രസിദ്ധീകരിക്കാൻ ഉദ്ദേശിച്ച ഡൈജസ്റ്റുകളുമായി താരതമ്യം ചെയ്യുക.

നിലവിലുള്ള ഒരു പതിപ്പ് അർത്ഥമാക്കാം മുൻപത്തെ അപ്‌ലോഡ് വിജയിച്ചു, മറുപടി നഷ്ടമായി, അല്ലെങ്കിൽ ആരോ അതേ നമ്പറിൽ വേറെ ഉള്ളടക്കം പ്രസിദ്ധീകരിച്ചു.

പതിപ്പ് മായ്ക്കരുത്, പിശക് ഒഴിവാക്കാൻ പുതിയ നമ്പർ കെട്ടിച്ചമയ്ക്കരുത്. സൂക്ഷിച്ച ഉള്ളടക്കം സ്വീകാര്യമാണോ എന്ന് റിലീസ് ഉടമയുമായി തീരുമാനിച്ച് ഫലം രേഖപ്പെടുത്തുക. ഉള്ളടക്കം വ്യത്യസ്തമാണെങ്കിൽ അത് പതിപ്പ് പ്രശ്നമാണ്, പൈപ്പ്‌ലൈൻ പ്രശ്നമല്ല.

അപ്‌ലോഡ് ക്രെഡൻഷ്യൽ ഒരു വശത്ത് സൂക്ഷിക്കുക

റിപ്പോസിറ്ററി ക്രെഡൻഷ്യലുകൾ ആന്തരിക പ്രസാധകന് മാത്രം വേണം, അപ്‌ലോഡ് നടക്കുന്ന സമയത്ത് മാത്രം. ടോക്കൺ ലക്ഷ്യ റിപ്പോസിറ്ററിയിലേക്കും അപ്‌ലോഡ് പ്രവർത്തനങ്ങളിലേക്കും പരിമിതപ്പെടുത്തുക, ആന്തരിക സംവിധാനത്തിന്റെ രഹസ്യ സംഭരണിയിൽ സൂക്ഷിക്കുക, ബിൽഡ് ജോലിയിൽ നിന്ന് പൂർണമായി ഒഴിവാക്കുക. ബിൽഡ് ജോലിക്ക് പ്രസിദ്ധീകരിക്കാനാകുമെങ്കിൽ, ബിൽഡ് മാറ്റാനാകുന്ന ആർക്കും പ്രസിദ്ധീകരിക്കാനാകും.

ഏത് ആന്തരിക വർക്ക്ഫ്ലോകൾക്ക് പ്രസാധകനെ തുടങ്ങാമെന്നും പരിമിതപ്പെടുത്തുക. നിർബന്ധിത അനുമതിയുള്ള കൈകൊണ്ടുള്ള ട്രിഗർ റിലീസുകൾക്ക് ന്യായമായ സ്ഥിരസ്ഥിതിയാണ്; ഏതെങ്കിലും ബ്രാഞ്ചിലേക്കുള്ള push അല്ല.

പൂർത്തിയായ റിലീസ് മൂന്ന് കാര്യങ്ങൾ ബാക്കിയാക്കണം: വിതരണ ഫയലുകൾ, സ്രോതസ്സ് റിവിഷനോടൊപ്പമുള്ള ഡൈജസ്റ്റുകൾ, അതേ പതിപ്പ് കാണിക്കുന്ന റിപ്പോസിറ്ററി രേഖ.