Bygg en Python-wheel utenfor nettverket, publiser den inneni

Du har allerede en build-jobb som produserer en wheel, og et privat repository som skal motta den. Feilen er å la en andre jobb bygge på nytt fra en branch og kalle resultatet samme utgivelse. Flytt filen som ble testet, navngi den etter digesten, og hold opplastingslegitimasjonen inneni. Gjennomgangen nedenfor følger én artefakt fra en offentlig CI-runner til en intern utgiver.

Bygg der kilden allerede ligger

Kjør bygget i jobben som allerede har kilden, verktøykjeden og testsuiten. Ingenting ved et privat repository krever at jobben når det. Installer build-frontenden i miljøet prosjektet allerede bruker, og produser deretter begge distribusjonsformatene hvis prosjektet leverer begge.

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

Hold utdatamappen liten og engangs. Det eneste som er verdt å ta med videre, er filene den neste jobben skal publisere, pluss hashene deres. Alt annet, inkludert virtuelle miljøer og cacher, kan bygges på nytt fra den registrerte kildeversjonen. En slank artefakt er også lettere å gjennomgå, fordi hver fil i den er en fil noen kan inspisere.

Registrer hva som produserte dem: pakkenavnet og versjonen fra filnavnene, kildeversjonen og workflow-kjøringen som lagde dem. En versjonsstreng alene identifiserer ikke en fil, fordi samme versjon kan bygges to ganger fra forskjellige commits. Skriv versjonen ved siden av filnavnene i artefaktbeskrivelsen, og behandle den registreringen som en del av overleveringen.

Flytt byte, ikke instruksjoner om å bygge på nytt

Et andre bygg er et andre produkt. Tidsstempler, medfølgende avhengigheter og verktøyversjoner kan alle endre bytene, så en ombygging trenger sine egne testbevis og sin egen gjennomgang. Forfrem i stedet de gjennomgåtte filene.

Last opp distribusjonsfilene til artefaktlageret CI-plattformen din tilbyr, og gi den interne jobben en referanse til nettopp den artefakten i stedet for et branchnavn.

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

Hvis plattformen din støtter signert opprinnelse, be den attestere artefakten og senere verifisere det forventede repositoryet, workflowen og kildeversjonen. GitHubs dokumentasjon om attestasjoner beskriver påstander av den formen. En gyldig signatur er opprinnelsesbevis, ikke en sårbarhetsskanning og ikke en autorisasjonsbeslutning.

Verifiser inneni før opplasting

Den interne jobben begynner med å kontrollere at filen den mottok, er filen som ble godkjent. Sammenlign digester med registreringen fra build-jobben, ikke med en verdi som er regnet ut på nytt fra det som ankom.

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

Les deretter metadataene. Pakkenavnet, versjonen og de deklarerte avhengighetene bør samsvare med gjennomgangen du godkjente. En wheel der navnet ser riktig ut, men avhengighetspinnene er endret, er en annen pakke med samme etikett. Hvis metadataene har flyttet seg, skal artefakten behandles som ikke godkjent, og du må finne ut hvilket bygg som produserte den.

Hvis digestene ikke stemmer, stopp. Ikke last opp, og ikke reparer filen ved å bygge den på nytt på stedet; det sletter beviset for at noe endret seg under transporten. Et avvik betyr at artefaktlageret, nedlastingssteget eller registreringen er feil, og hver av dem fortjener en forklaring før en utgivelse publiseres.

Håndter svaret om duplikatversjon

Private repositoryer nekter vanligvis å overskrive en eksisterende versjon, og den nektelsen er en funksjon. Når en opplasting feiler fordi versjonen finnes, undersøk repositoryets registrering for den versjonen og sammenlign filene den holder med digestene du hadde tenkt å publisere.

En eksisterende versjon kan bety at en tidligere opplasting lyktes og svaret gikk tapt, eller at noen har publisert annet innhold under samme nummer.

Ikke slett versjonen, og ikke finn opp et nytt nummer for å komme rundt feilen. Bestem sammen med utgivelseseieren om det lagrede innholdet er akseptabelt, og registrer så resultatet. Hvis innholdet avviker, har du et versjonsproblem, ikke et pipeline-problem.

Hold opplastingslegitimasjonen på én side

Bare den interne utgiveren trenger repository-legitimasjon, og bare så lenge opplastingen varer. Begrens tokenet til mål-repositoryet og til opplastingsoperasjoner, hold det i det interne systemets hemmelige lager, og hold det helt utenfor build-jobben. Hvis build-jobben kan publisere, kan enhver som kan endre bygget, publisere.

Begrens også hvilke interne arbeidsflyter som kan starte utgiveren. En manuell utløser med påkrevd godkjenning er en rimelig standard for utgivelser; en push til hvilken som helst branch er det ikke.

Den ferdige utgivelsen bør etterlate tre ting: distribusjonsfilene, digestene deres sammen med kildeversjonen, og en repository-registrering som viser samme versjon.