Byg en Python-wheel uden for netværket, udgiv den indeni

Du har allerede et build-job, der producerer en wheel, og et privat repository, som skal modtage den. Fejlen er at lade et andet job genopbygge fra en branch og kalde resultatet samme udgivelse. Flyt den fil, der blev testet, navngiv den efter digesten, og hold upload-legitimationsoplysningerne indeni. Gennemgangen nedenfor følger et artefakt fra en offentlig CI-runner til en intern udgiver.

Byg der, hvor kilden allerede ligger

Kør buildet i det job, der allerede har kilden, værktøjskæden og testsuiten. Intet ved et privat repository kræver, at jobbet når det. Installér build-frontenden i det miljø, projektet allerede bruger, og producér derefter begge distributionsformater, hvis projektet leverer begge.

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

Hold outputmappen lille og engangs. Det eneste, der er værd at tage videre, er de filer, som det næste job skal udgive, plus deres hashes. Alt andet, inklusive virtuelle miljøer og caches, kan genopbygges fra den registrerede kilderevision. Et slankt artefakt er også lettere at gennemgå, fordi hver fil i det er en fil, nogen kan inspicere.

Registrér, hvad der producerede dem: pakkenavnet og versionen fra filnavnene, kilderevisionen og workflow-kørslen, der skabte dem. En versionsstreng alene identificerer ikke en fil, fordi samme version kan bygges to gange fra forskellige commits. Skriv revisionen ved siden af filnavnene i artefaktbeskrivelsen, og behandl den registrering som en del af overdragelsen.

Flyt bytes, ikke instruktioner om at genopbygge

Et andet build er et andet produkt. Tidsstempler, medtagede afhængigheder og værktøjsversioner kan alle ændre bytes, så en genopbygning kræver sit eget testbevis og sin egen gennemgang. Forfrem i stedet de gennemgåede filer.

Upload distributionsfilerne til det artefaktlager, din CI-platform stiller til rådighed, og giv det interne job en reference til netop det artefakt i stedet for et branchnavn.

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

Hvis din platform understøtter signeret oprindelse, så bed den attestere artefakten og senere verificere det forventede repository, workflow og kilderevision. GitHubs dokumentation om attestationer beskriver påstande af den form. En gyldig signatur er oprindelsesbevis, ikke en sårbarhedsscanning og ikke en autorisationsbeslutning.

Verificér indeni før upload

Det interne job begynder med at kontrollere, at den fil, det modtog, er den fil, der blev godkendt. Sammenlign digests med registreringen fra build-jobbet, ikke med en værdi, der er genberegnet ud fra det, der er ankommet.

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

Læs derefter metadataene. Pakkenavnet, versionen og de deklarerede afhængigheder bør stemme med den gennemgang, du godkendte. En wheel, hvis navn ser rigtigt ud, men hvis afhængighedspins er ændret, er en anden pakke med samme etiket. Hvis metadataene har flyttet sig, skal artefakten behandles som ikke godkendt, og find ud af, hvilket build der producerede den.

Hvis digestsene ikke stemmer, så stop. Upload ikke, og reparér ikke filen ved at genopbygge den på stedet; det sletter beviset for, at noget ændrede sig under transporten. En afvigelse betyder, at artefaktlageret, downloadtrinnet eller registreringen er forkert, og hver af dem fortjener en forklaring, før en udgivelse publiceres.

Håndtér svaret om dubletversion

Private repositories afviser normalt at overskrive en eksisterende version, og den afvisning er en funktion. Når en upload fejler, fordi versionen findes, så undersøg repositoryets registrering for den version og sammenlign de filer, den rummer, med de digests, du havde tænkt dig at publicere.

En eksisterende version kan betyde, at en tidligere upload lykkedes, og at svaret gik tabt, eller at nogen har publiceret andet indhold under samme nummer.

Slet ikke versionen, og opfind ikke et nyt nummer for at komme uden om fejlen. Beslut sammen med udgivelsesejeren, om det lagrede indhold er acceptabelt, og registrér så resultatet. Hvis indholdet afviger, har du et versionsproblem, ikke et pipelineproblem.

Hold upload-legitimationsoplysningerne på én side

Kun den interne udgiver har brug for repository-legitimationsoplysninger, og kun så længe uploadet varer. Afgræns tokenet til mål-repositoryet og til upload-operationer, hold det i det interne systems secret store, og hold det helt ude af build-jobbet. Hvis build-jobbet kan publicere, så kan enhver, der kan ændre buildet, publicere.

Begræns også, hvilke interne workflows der må starte udgiveren. En manuel trigger med en påkrævet godkendelse er en rimelig standard for udgivelser; et push til en vilkårlig branch er det ikke.

Den færdige udgivelse bør efterlade tre ting: distributionsfilerne, deres digests sammen med kilderevisionen og en repository-registrering, der viser samme version.