Bygg en Python-wheel utanför nätet och publicera den innanför

Du har redan ett byggjobb som producerar en wheel och ett privat arkiv som ska ta emot den. Misstaget är att låta ett andra jobb bygga om från en gren och kalla resultatet samma utgåva. Flytta filen som testades, namnge den efter digestvärdet och håll uppladdningsuppgifterna på insidan. Genomgången nedan följer en artefakt från en offentlig CI-runner till en intern utgivare.

Bygg där källkoden redan finns

Kör bygget i jobbet som redan har källkoden, verktygskedjan och testsviten. Inget med ett privat arkiv kräver att det jobbet når det. Installera byggfrontend i den miljö projektet redan använder och producera sedan båda distributionsformaten om projektet levererar båda.

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

Håll utdatakatalogen liten och engångsmässig. Det enda som är värt att föra vidare är filerna som nästa jobb ska publicera, plus deras hashvärden. Allt annat, inklusive virtuella miljöer och cachar, kan byggas om från den registrerade källrevisionen. En slimmad artefakt är också lättare att granska, eftersom varje fil i den är en fil som någon kan inspektera.

Registrera vad som producerade dem: paketnamnet och versionen från filnamnen, källrevisionen och den workflow-körning som skapade dem. En versionssträng ensam identifierar inte en fil, eftersom samma version kan byggas två gånger från olika commits. Skriv revisionen bredvid filnamnen i artefaktens beskrivning och behandla den posten som en del av överlämningen.

Flytta byte, inte instruktioner att bygga om

Ett andra bygge är en andra produkt. Tidsstämplar, inbäddade beroenden och verktygsversioner kan alla ändra byten, så ett ombygge behöver sina egna testbevis och sin egen granskning. Befordra de granskade filerna i stället.

Ladda upp distributionsfilerna till den artefaktlagring som din CI-plattform tillhandahåller och ge det interna jobbet en referens till just den artefakten i stället för ett grennamn.

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

Om din plattform stöder signerat ursprung, be den attestera artefakten och verifiera sedan det förväntade arkivet, workflowet och källrevisionen. GitHubs dokumentation om attesteringar beskriver påståenden av den formen. En giltig signatur är ursprungsbevis, inte en sårbarhetsskanning och inte ett auktoriseringsbeslut.

Verifiera på insidan före uppladdning

Det interna jobbet börjar med att kontrollera att filen det fick är filen som godkändes. Jämför digestvärden mot posten från byggjobbet, inte mot ett värde som räknats om från det som anlände.

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

Läs sedan metadata. Paketnamnet, versionen och de deklarerade beroendena ska stämma med den granskning du godkände. En wheel vars namn ser rätt ut men vars beroendepinnar ändrats är ett annat paket med samma etikett. Om metadata har flyttats, behandla artefakten som ej godkänd och ta reda på vilket bygge som producerade den.

Om digestvärdena inte stämmer, stoppa. Ladda inte upp och reparera inte filen genom att bygga om den på plats; det raderar beviset att något ändrades under transporten. En avvikelse betyder att artefaktlagringen, nedladdningssteget eller posten är fel, och var och en av dem förtjänar en förklaring innan en utgåva publiceras.

Hantera svaret om dubblettversion

Privata arkiv vägrar vanligtvis att skriva över en befintlig version, och den vägran är en funktion. När en uppladdning misslyckas för att versionen finns, granska arkivets post för den versionen och jämför filerna den håller med de digestvärden du tänkte publicera.

En befintlig version kan betyda att en tidigare uppladdning lyckades och svaret gick förlorat, eller att någon publicerade annat innehåll under samma nummer.

Radera inte versionen och hitta inte på ett nytt nummer för att komma förbi felet. Bestäm med utgåvans ägare om det lagrade innehållet är acceptabelt och registrera sedan utfallet. Om innehållet skiljer sig har du ett versionsproblem, inte ett pipelineproblem.

Håll uppladdningsuppgifterna på en sida

Bara den interna utgivaren behöver arkivuppgifter, och bara under uppladdningens längd. Begränsa token till målarkivet och till uppladdningsoperationer, förvara den i det interna systemets hemlighetslager och håll den helt utanför byggjobbet. Om byggjobbet kan publicera kan alla som kan ändra bygget publicera.

Begränsa också vilka interna workflows som får starta utgivaren. En manuell utlösare med krav på godkännande är en rimlig standard för utgåvor; en push till vilken gren som helst är det inte.

Den färdiga utgåvan bör lämna tre saker efter sig: distributionsfilerna, deras digestvärden med källrevisionen och en arkivpost som visar samma version.