Python wheel ను నెట్‌వర్క్ వెలుపల నిర్మించి లోపల ప్రచురించండి

wheel ఉత్పత్తి చేసే బిల్డ్ పని మరియు దానిని స్వీకరించాల్సిన ప్రైవేట్ రిపాజిటరీ ఇప్పటికే మీకు ఉన్నాయి. ఒక బ్రాంచ్ నుండి మరో పని తిరిగి నిర్మించి, ఆ ఫలితాన్నే అదే విడుదల అని పిలవడం తప్పు. పరీక్షించిన ఫైలునే తరలించండి, దానిని డైజెస్ట్‌తో పేరు పెట్టండి, అప్‌లోడ్ ఆధారాలను లోపలే ఉంచండి. క్రింది వివరణ ఒక artifact ను పబ్లిక్ CI runner నుండి అంతర్గత ప్రచురకుడి వరకు అనుసరిస్తుంది.

సోర్స్ ఇప్పటికే ఉన్న చోటే నిర్మించండి

సోర్స్, టూల్‌చైన్ మరియు పరీక్షల సెట్ ఇప్పటికే ఉన్న పనిలోనే బిల్డ్‌ను అమలు చేయండి. ప్రైవేట్ రిపాజిటరీ కోసం ఆ పని దానిని చేరుకోవాల్సిన అవసరం లేదు. ప్రాజెక్ట్ ఇప్పటికే ఉపయోగిస్తున్న వాతావరణంలో బిల్డ్ frontend ను ఇన్‌స్టాల్ చేయండి, ప్రాజెక్ట్ రెండింటినీ పంపిస్తే రెండు పంపిణీ రూపాలను తయారు చేయండి.

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

అవుట్‌పుట్ డైరెక్టరీని చిన్నదిగా, ఒకసారి వాడేదిగా ఉంచండి. తదుపరి పని ప్రచురించే ఫైళ్లు మరియు వాటి హాష్‌లు మాత్రమే ముందుకు తీసుకెళ్లదగినవి. వర్చువల్ వాతావరణాలు, కాష్‌లతో సహా మిగతావన్నీ నమోదు చేసిన సోర్స్ రివిజన్ నుండి తిరిగి నిర్మించవచ్చు. సన్నని artifact సమీక్షించడం కూడా సులభం, ఎందుకంటే దానిలోని ప్రతి ఫైలు ఎవరైనా పరిశీలించగలిగిన ఫైలే.

వాటిని ఉత్పత్తి చేసినది నమోదు చేయండి: ఫైల్ పేర్ల నుండి ప్యాకేజీ పేరు మరియు వెర్షన్, సోర్స్ రివిజన్, మరియు వాటిని సృష్టించిన workflow రన్. వెర్షన్ స్ట్రింగ్ ఒక్కటే ఫైలును గుర్తించదు, ఎందుకంటే అదే వెర్షన్‌ను వేర్వేరు commit ల నుండి రెండుసార్లు నిర్మించవచ్చు. artifact వివరణలో ఫైల్ పేర్ల పక్కన రివిజన్ రాయండి, ఆ నమోదును అప్పగింపులో భాగంగా పరిగణించండి.

బైట్లను తరలించండి, తిరిగి నిర్మించే సూచనలను కాదు

రెండవ బిల్డ్ రెండవ ఉత్పత్తి. టైమ్‌స్టాంపులు, బండిల్ చేసిన డిపెండెన్సీలు, టూల్ వెర్షన్‌లు అన్నీ బైట్లను మార్చగలవు, కాబట్టి తిరిగి నిర్మాణానికి దాని సొంత పరీక్ష రుజువు, సొంత సమీక్ష అవసరం. బదులుగా సమీక్షించిన ఫైళ్లను ముందుకు తీసుకెళ్లండి.

మీ CI ప్లాట్‌ఫారం అందించే artifact నిల్వకు పంపిణీ ఫైళ్లను అప్‌లోడ్ చేయండి, అంతర్గత పనికి బ్రాంచ్ పేరు బదులు ఆ నిర్దిష్ట artifact సూచన ఇవ్వండి.

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

మీ ప్లాట్‌ఫారం సంతకం చేసిన మూలాన్ని మద్దతిస్తే, artifact ను ధ్రువీకరించమని అడగండి, తర్వాత ఆశించిన రిపాజిటరీ, workflow మరియు సోర్స్ రివిజన్‌ను ధృవీకరించండి. GitHub యొక్క ధ్రువీకరణ పత్రం ఆ రూపంలోని వాదనలను వివరిస్తుంది. చెల్లుబాటు అయ్యే సంతకం మూలానికి రుజువు, ఇది హాని స్కాన్ కాదు, అనుమతి నిర్ణయం కూడా కాదు.

అప్‌లోడ్ చేసే ముందు లోపల ధృవీకరించండి

అంతర్గత పని మొదలవ్వడం, అందుకున్న ఫైలు ఆమోదించిన ఫైలే అని తనిఖీ చేయడంతోనే. డైజెస్ట్‌లను బిల్డ్ పని నమోదుతో పోల్చండి, వచ్చిన దాని నుండి తిరిగి లెక్కించిన విలువతో కాదు.

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

తర్వాత metadata చదవండి. ప్యాకేజీ పేరు, వెర్షన్, ప్రకటించిన డిపెండెన్సీలు మీరు ఆమోదించిన సమీక్షకు సరిపోలాలి. పేరు సరిగ్గా కనిపిస్తున్నా దాని డిపెండెన్సీ పిన్‌లు మారిన wheel వేరే ప్యాకేజీ అదే లేబుల్‌ను మోస్తోంది. metadata కదిలితే, artifact ను ఆమోదించనిదిగా పరిగణించి ఏ బిల్డ్ దానిని ఉత్పత్తి చేసిందో కనుగొనండి.

డైజెస్ట్‌లు సరిపోలకపోతే ఆపండి. అప్‌లోడ్ చేయవద్దు, ఫైలును అక్కడే తిరిగి నిర్మించి బాగు చేయవద్దు; అది దారిలో ఏదో మారినట్లు రుజువును తుడిచివేస్తుంది. సరిపోలకపోవడం అంటే artifact నిల్వ, డౌన్‌లోడ్ దశ లేదా నమోదు తప్పు, వాటిలో ప్రతిదీ విడుదల ప్రచురించే ముందు వివరణ పొందాలి.

నకిలీ వెర్షన్ సమాధానాన్ని నిర్వహించండి

ప్రైవేట్ రిపాజిటరీలు సాధారణంగా ఉన్న వెర్షన్‌ను ఓవర్‌రైట్ చేయడానికి నిరాకరిస్తాయి, ఆ నిరాకరణ ఒక లక్షణం. వెర్షన్ ఉన్నందున అప్‌లోడ్ విఫలమైతే, ఆ వెర్షన్ కోసం రిపాజిటరీ నమోదును పరిశీలించి, అది ఉంచిన ఫైళ్లను మీరు ప్రచురించాలనుకున్న డైజెస్ట్‌లతో పోల్చండి.

ఉన్న వెర్షన్ అంటే మునుపటి అప్‌లోడ్ విజయవంతమై సమాధానం పోయిందని, లేదా ఎవరో అదే సంఖ్య కింద వేరే కంటెంట్ ప్రచురించారని కావచ్చు.

వెర్షన్‌ను తొలగించవద్దు, లోపాన్ని దాటడానికి కొత్త సంఖ్యను కల్పించవద్దు. నిల్వ ఉన్న కంటెంట్ ఆమోదయోగ్యమా అని విడుదల యజమానితో నిర్ణయించి, తర్వాత ఫలితాన్ని నమోదు చేయండి. కంటెంట్ భిన్నంగా ఉంటే, మీకు వెర్షనింగ్ సమస్య ఉంది, pipeline సమస్య కాదు.

అప్‌లోడ్ ఆధారాన్ని ఒక వైపే ఉంచండి

రిపాజిటరీ ఆధారాలు అంతర్గత ప్రచురకుడికి మాత్రమే అవసరం, అప్‌లోడ్ కాలం వరకే. token ను లక్ష్య రిపాజిటరీకి, అప్‌లోడ్ కార్యకలాపాలకు పరిమితం చేయండి, అంతర్గత వ్యవస్థ రహస్య నిల్వలో ఉంచండి, బిల్డ్ పని నుండి పూర్తిగా బయట ఉంచండి. బిల్డ్ పని ప్రచురించగలిగితే, బిల్డ్‌ను మార్చగల ఎవరైనా ప్రచురించగలరు.

ఏ అంతర్గత workflow లు ప్రచురకుడిని ప్రారంభించవచ్చో కూడా పరిమితం చేయండి. తప్పనిసరి ఆమోదంతో కూడిన చేతితో చేసే ప్రేరణ విడుదలలకు సరైన డిఫాల్ట్; ఏ బ్రాంచ్‌కైనా push కాదు.

పూర్తయిన విడుదల మూడు విషయాలను మిగల్చాలి: పంపిణీ ఫైళ్లు, సోర్స్ రివిజన్‌తో కూడిన వాటి డైజెస్ట్‌లు, అదే వెర్షన్‌ను చూపే రిపాజిటరీ నమోదు.