Bygg ein Python-wheel utanfor nettet, publiser han innanfor

Du har alt ein byggjobb som lagar ein wheel, og eit privat depot som skal ta imot han. Feilen er å la ein annan jobb byggje på nytt frå ein grein og kalle resultatet same utgåve. Flytt fila som vart testa, namnset henne etter digesten, og hald opplastingslegitimasjonen innanfor. Gjennomgangen nedanfor følgjer ein artefakt frå ein offentleg CI-køyrar til ein intern utgjevar.

Bygg der kjelda alt ligg

Køyr bygget i jobben som alt har kjelda, verktøykjeda og testpakken. Ingenting ved eit privat depot krev at jobben når det. Installer byggjefrontenden i miljøet prosjektet alt brukar, og lag så begge distribusjonsformata om prosjektet leverer begge.

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

Hald utmappa lita og eingongs. Det einaste som er verdt å ta med vidare, er filene den neste jobben skal publisere, pluss hasjane deira. Alt anna, medrekna virtuelle miljø og cachar, kan byggjast på nytt frå den registrerte kjeldeversjonen. Ein slank artefakt er òg lettare å gå gjennom, fordi kvar fil i han er ei fil nokon kan inspisere.

Registrer kva som laga dei: pakkenamnet og versjonen frå filnamna, kjeldeversjonen og arbeidsflytkøyringa som skapte dei. Ein versjonsstreng åleine identifiserer ikkje ei fil, fordi same versjon kan byggjast to gonger frå ulike commitar. Skriv versjonen ved sida av filnamna i artefaktomtalen, og handsam den registreringa som ein del av overleveringa.

Flytt byte, ikkje instruksar om å byggje på nytt

Eit andre bygg er eit andre produkt. Tidsstempel, medfølgde avhengnader og verktøyversjonar kan alle endre byta, så ein ombygging treng eigne testbevis og eigen gjennomgang. Fremje i staden dei gjennomgåtte filene.

Last opp distribusjonsfilene til artefaktlageret CI-plattforma di tilbyr, og gje den interne jobben ei tilvising til nettopp den artefakten i staden for eit greinnamn.

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

Om plattforma di støttar signert opphav, be henne attestere artefakten og seinare verifisere det forventa depotet, arbeidsflyten og kjeldeversjonen. GitHubs dokumentasjon om attestasjonar skildrar påstandar av den forma. Ein gyldig signatur er opphavsbevis, ikkje ein sårbarhetsskann og ikkje ei autorisasjonsavgjerd.

Verifiser innanfor før opplasting

Den interne jobben byrjar med å kontrollere at fila han fekk, er fila som vart godkjend. Samanlikn digestar med registreringa frå byggjobben, ikkje med ein verdi som er rekna ut på nytt frå det som kom inn.

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

Les så metadataa. Pakkenamnet, versjonen og dei deklarerte avhengnadene bør stemme med gjennomgangen du godkjende. Ein wheel der namnet ser rett ut, men avhengnadspinnane er endra, er ein annan pakke med same etikett. Om metadataa har flytta seg, skal artefakten handsamast som ikkje godkjend, og du må finne ut kva bygg som laga han.

Om digestane ikkje stemmer, stopp. Ikkje last opp, og ikkje reparer fila ved å byggje henne på nytt på staden; det slettar beviset for at noko endra seg under transporten. Eit avvik betyr at artefaktlageret, nedlastingssteget eller registreringa er feil, og kvar av dei fortener ei forklaring før ei utgåve blir publisert.

Handsam svaret om duplikatversjon

Private depot nektar vanlegvis å overskrive ein eksisterande versjon, og den nektinga er ein funksjon. Når ei opplasting feilar fordi versjonen finst, undersøk registreringa til depotet for den versjonen og samanlikn filene han held med digestane du hadde tenkt å publisere.

Ein eksisterande versjon kan tyde på at ei tidlegare opplasting lukkast og svaret gjekk tapt, eller at nokon har publisert anna innhald under same nummer.

Ikkje slett versjonen, og ikkje finn opp eit nytt nummer for å kome rundt feilen. Avgjer saman med utgåveeigaren om det lagra innhaldet er akseptabelt, og registrer så resultatet. Om innhaldet avvik, har du eit versjonsproblem, ikkje eit pipeline-problem.

Hald opplastingslegitimasjonen på éi side

Berre den interne utgjevaren treng depotlegitimasjon, og berre så lenge opplastinga varer. Afgrens tokenet til mål-depotet og til opplastingsoperasjonar, hald det i det hemmelege lageret til det interne systemet, og hald det heilt utanfor byggjobben. Om byggjobben kan publisere, kan kven som helst som kan endre bygget, publisere.

Avgrens òg kva interne arbeidsflytar som kan starte utgjevaren. Ein manuell utløysar med påkravd godkjenning er ein rimeleg standard for utgåver; ein push til kva grein som helst er det ikkje.

Den ferdige utgåva bør etterlate tre ting: distribusjonsfilene, digestane deira saman med kjeldeversjonen, og ei depotregistrering som viser same versjon.