Ստեղծեք Python wheel ցանցից դուրս և հրապարակեք այն ներսում

Դուք արդեն ունեք build աշխատանք, որը ստեղծում է wheel, և մասնավոր պահոց, որը պետք է ստանա այն։ Սխալն այն է, երբ թույլ տաք, որ երկրորդ աշխատանքը ճյուղից նորից կառուցի և արդյունքը անվանի նույն թողարկում։ Տեղափոխեք այն ֆայլը, որը փորձարկվել է, անվանեք այն դայջեսթով և վերբեռնման հավատարմագրումը պահեք ներսում։ Ստորև նկարագրված ընթացքը հետևում է մեկ արտեֆակտի՝ հանրային CI runner-ից մինչև ներքին հրապարակող։

Կառուցեք այնտեղ, որտեղ արդեն կա սկզբնաղբյուրը

Կատարեք build-ը այն աշխատանքում, որտեղ արդեն կա սկզբնաղբյուրը, գործիքային շղթան և թեստային հավաքածուն։ Մասնավոր պահոցի հետ կապված ոչինչ չի պահանջում, որ այդ աշխատանքը հասնի դրան։ Տեղադրեք build-ի frontend-ը այն միջավայրում, որն արդեն օգտագործում է նախագիծը, ապա արտադրեք բաշխման երկու ձևաչափերն էլ, եթե նախագիծը երկուսն էլ է տրամադրում։

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

Ելքի պանակը պահեք փոքր և մեկանգամյա։ Առաջ տանելու արժանի միակ բաները այն ֆայլերն են, որոնք կհրապարակի հաջորդ աշխատանքը, գումարած դրանց հեշերը։ Մնացած ամեն ինչ, ներառյալ վիրտուալ միջավայրերն ու քեշերը, կարելի է նորից կառուցել գրանցված սկզբնաղբյուրի տարբերակից։ Նիհար արտեֆակտն ավելի հեշտ է ստուգել, որովհետև դրա ամեն ֆայլ այնպիսի ֆայլ է, որ որևէ մեկը կարող է զննել։

Գրանցեք, թե ինչ է արտադրել դրանք՝ փաթեթի անունն ու տարբերակը ֆայլերի անուններից, սկզբնաղբյուրի տարբերակը և այն workflow-ի աշխատանքը, որը ստեղծել է դրանք։ Միայն տարբերակի տողը չի նույնականացնում ֆայլը, որովհետև նույն տարբերակը կարելի է երկու անգամ կառուցել տարբեր commit-ներից։ Գրեք տարբերակը ֆայլերի անունների կողքին՝ արտեֆակտի նկարագրության մեջ, և այդ գրառումը համարեք հանձնման մաս։

Տեղափոխեք բայթեր, ոչ թե վերակառուցման հրահանգներ

Երկրորդ build-ը երկրորդ արտադրանքն է։ Ժամանակի դրոշմները, փաթեթավորված կախվածությունները և գործիքների տարբերակները կարող են փոխել բայթերը, ուստի վերակառուցմանը պետք են իր իսկ թեստային ապացույցը և իր իսկ վերանայումը։ Փոխարենը առաջ տարեք վերանայված ֆայլերը։

Վերբեռնեք բաշխման ֆայլերը ձեր CI հարթակի տրամադրած արտեֆակտների պահոց, և ներքին աշխատանքին տվեք հղում հենց այդ արտեֆակտին, ոչ թե ճյուղի անվանը։

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

Եթե ձեր հարթակը աջակցում է ստորագրված ծագմանը, խնդրեք այն հաստատել արտեֆակտը և ավելի ուշ ստուգել ակնկալվող պահոցը, workflow-ը և սկզբնաղբյուրի տարբերակը։ GitHub-ի հաստատման փաստաթղթերը նկարագրում են այդ ձևի պնդումներ։ Վավեր ստորագրությունը ծագման ապացույց է, ոչ խոցելիությունների սկանավորում և ոչ էլ լիազորման որոշում։

Ներսում ստուգեք վերբեռնելուց առաջ

Ներքին աշխատանքը սկսվում է ստուգելով, որ ստացված ֆայլը հենց այն ֆայլն է, որը հաստատվել է։ Համեմատեք դայջեսթները build աշխատանքի գրառման հետ, ոչ թե արժեքի հետ, որը վերահաշվարկվել է եկածից։

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

Ապա կարդացեք մետատվյալները։ Փաթեթի անունը, տարբերակը և հայտարարված կախվածությունները պետք է համապատասխանեն ձեր հաստատած վերանայմանը։ Այն wheel-ը, որի անունը ճիշտ է թվում, բայց կախվածությունների pin-երը փոխվել են, այլ փաթեթ է՝ նույն պիտակով։ Եթե մետատվյալները շարժվել են, արտեֆակտը համարեք չհաստատված և պարզեք, թե որ build-ն է արտադրել այն։

Եթե դայջեսթները չեն համապատասխանում, կանգ առեք։ Մի վերբեռնեք և մի՛ վերանորոգեք ֆայլը տեղում վերակառուցելով. դա ջնջում է այն ապացույցը, որ ինչ-որ բան փոխվել է փոխադրման ընթացքում։ Անհամապատասխանությունը նշանակում է, որ արտեֆակտների պահոցը, ներբեռնման քայլը կամ գրառումը սխալ են, և դրանցից յուրաքանչյուրը բացատրության կարիք ունի մինչև թողարկման հրապարակումը։

Լուծեք կրկնվող տարբերակի պատասխանը

Մասնավոր պահոցները սովորաբար հրաժարվում են վերագրանցել գոյություն ունեցող տարբերակը, և այդ մերժումը առանձնահատկություն է։ Երբ վերբեռնումը ձախողվում է, որովհետև տարբերակը կա, զննեք պահոցի գրառումն այդ տարբերակի համար և համեմատեք այն պարունակած ֆայլերը ձեր հրապարակելիք դայջեսթների հետ։

Գոյություն ունեցող տարբերակը կարող է նշանակել, որ նախորդ վերբեռնումը հաջողվել է, և պատասխանը կորել է, կամ որ ինչ-որ մեկը նույն համարի տակ այլ բովանդակություն է հրապարակել։

Մի՛ ջնջեք տարբերակը և մի՛ հնարեք նոր համար՝ սխալը շրջանցելու համար։ Թողարկման պատասխանատուի հետ որոշեք՝ արդյոք պահված բովանդակությունը ընդունելի է, ապա գրանցեք արդյունքը։ Եթե բովանդակությունը տարբերվում է, դուք ունեք տարբերակման խնդիր, ոչ թե pipeline-ի խնդիր։

Վերբեռնման հավատարմագրումը պահեք մի կողմում

Պահոցի հավատարմագրեր պետք են միայն ներքին հրապարակողին և միայն վերբեռնման տևողության համար։ Սահմանափակեք token-ը թիրախ պահոցով և վերբեռնման գործողություններով, պահեք այն ներքին համակարգի գաղտնիքների պահոցում և ամբողջությամբ թողեք build աշխատանքից դուրս։ Եթե build աշխատանքը կարող է հրապարակել, ապա ցանկացած ոք, ով կարող է փոխել build-ը, կարող է հրապարակել։

Սահմանափակեք նաև, թե որ ներքին workflow-ները կարող են մեկնարկել հրապարակողին։ Պարտադիր հաստատմամբ ձեռքով գործարկիչը թողարկումների համար ողջամիտ լռելյայն է. ցանկացած ճյուղ push անելը՝ ոչ։

Ավարտված թողարկումը պետք է թողնի երեք բան՝ բաշխման ֆայլերը, դրանց դայջեսթները սկզբնաղբյուրի տարբերակի հետ և պահոցի գրառում, որը ցույց է տալիս նույն տարբերակը։