Ndërto një wheel Python jashtë rrjetit dhe publikoje brenda

Ju tashmë keni një punë ndërtimi që prodhon një wheel dhe një depo private që duhet ta marrë atë. Gabimi është t'i lini një pune të dytë ta rindërtojë nga një degë dhe ta quani rezultatin e njëjta publikim. Zhvendosni skedarin që u testua, emërtojeni sipas digestit dhe mbajini kredencialet e ngarkimit brenda. Udhëzimi më poshtë ndjek një artefakt nga një runner CI publik deri te një botues i brendshëm.

Ndërto aty ku kodi burim ndodhet tashmë

Xeni ndërtimin në punën që ka tashmë kodin burim, zinxhirin e veglave dhe grupin e testeve. Asgjë te një depo private nuk kërkon që kjo punë ta arrijë atë. Instaloni frontend-in e ndërtimit në mjedisin që projekti përdor tashmë, pastaj prodhoni të dy format e shpërndarjes nëse projekti i dërgon të dyja.

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

Mbajeni drejtorinë e daljes të vogël dhe njëpërdorimshe. Të vetmet gjëra që ia vlen të çohen përpara janë skedarët që do të publikojë puna tjetër, plus hash-et e tyre. Çdo gjë tjetër, përfshirë mjediset virtuale dhe cache-t, mund të rindërtohet nga rishikimi i burimit i regjistruar. Një artefakt i dobët është gjithashtu më i lehtë për t'u rishikuar, sepse çdo skedar në të është një skedar që dikush mund ta inspektojë.

Regjistroni çfarë i prodhoi: emrin e paketës dhe versionin nga emrat e skedarëve, rishikimin e burimit dhe ekzekutimin e workflow-it që i krijoi. Vetëm një varg versioni nuk e identifikon një skedar, sepse i njëjti version mund të ndërtohet dy herë nga commit-e të ndryshme. Shkruani rishikimin pranë emrave të skedarëve në përshkrimin e artefaktit dhe trajtojeni atë regjistrim si pjesë të dorëzimit.

Zhvendos bajt, jo udhëzime për rindërtim

Një ndërtim i dytë është një produkt i dytë. Vulat kohore, varësitë e paketuara dhe versionet e veglave mund t'i ndryshojnë bajt, prandaj një rindërtim kërkon provat e veta të testimit dhe rishikimin e vet. Në vend të kësaj promovoni skedarët e rishikuar.

Ngarkoni skedarët e shpërndarjes në depon e artefakteve që ofron platforma juaj CI dhe jepini punës së brendshme një referencë për atë artefakt specifik, jo një emër dege.

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

Nëse platforma juaj mbështet origjinë të nënshkruar, kërkojini të vërtetojë artefaktin dhe më vonë verifikoni depon, workflow-in dhe rishikimin e burimit të pritur. Dokumentacioni i vërtetimeve i GitHub përshkruan pretendime të atij lloji. Një nënshkrim i vlefshëm është provë origjine, jo një skanim dobësish dhe jo një vendim autorizimi.

Verifiko brenda përpara ngarkimit

Puna e brendshme fillon duke kontrolluar që skedari i marrë është skedari që u miratua. Krahasoni digestet me regjistrimin nga puna e ndërtimit, jo me një vlerë të rillogaritur nga ajo që mbërriti.

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

Pastaj lexoni metadata. Emri i paketës, versioni dhe varësitë e deklaruara duhet të përputhen me rishikimin që miratuat. Një wheel emri i të cilit duket i saktë por fiksimet e varësive të të cilit ndryshuan është një paketë tjetër që mban të njëjtën etiketë. Nëse metadata lëvizi, trajtojeni artefaktin si të pamiratuar dhe zbuloni cili ndërtim e prodhoi.

Nëse digestet nuk përputhen, ndaloni. Mos ngarkoni dhe mos e riparoni skedarin duke e rindërtuar në vend; kjo fshin provën që diçka ndryshoi gjatë rrugës. Një mospërputhje do të thotë që depoja e artefakteve, hapi i shkarkimit ose regjistrimi është i gabuar, dhe secili prej tyre meriton një shpjegim përpara se të publikohet një version.

Trajtoni përgjigjen e versionit të dyfishtë

Depot private zakonisht refuzojnë të mbishkruajnë një version ekzistues, dhe ky refuzim është një veçori. Kur një ngarkim dështon sepse versioni ekziston, inspektoni regjistrimin e depos për atë version dhe krahasoni skedarët që mban me digestet që kishit ndërmend të publikonit.

Një version ekzistues mund të nënkuptojë që një ngarkim i mëparshëm pati sukses dhe përgjigja u humb, ose që dikush publikoi përmbajtje tjetër nën të njëjtin numër.

Mos e fshini versionin dhe mos shpikni një numër të ri për të kaluar gabimin. Vendosni me pronarin e publikimit nëse përmbajtja e ruajtur është e pranueshme, pastaj regjistroni rezultatin. Nëse përmbajtja ndryshon, keni një problem versionimi, jo një problem pipeline.

Mbajeni kredencialin e ngarkimit nga një anë

Vetëm botuesi i brendshëm ka nevojë për kredenciale depoje, dhe vetëm për kohëzgjatjen e ngarkimit. Kufizoni tokenin te depoja e synuar dhe te operacionet e ngarkimit, mbajeni në depon e sekreteve të sistemit të brendshëm dhe lëreni plotësisht jashtë punës së ndërtimit. Nëse puna e ndërtimit mund të publikojë, atëherë kushdo që mund të ndryshojë ndërtimin mund të publikojë.

Kufizoni gjithashtu cilat workflow të brendshme mund të nisin botuesin. Një nxitës manual me miratim të detyrueshëm është një parazgjedhje e arsyeshme për publikimet; një push në çdo degë nuk është.

Publikimi i përfunduar duhet të lërë pas tre gjëra: skedarët e shpërndarjes, digestet e tyre me rishikimin e burimit dhe një regjistrim depoje që tregon të njëjtin version.