Rakenna Python-wheel verkon ulkopuolella ja julkaise se sisällä

Sinulla on jo build-työ, joka tuottaa wheelin, ja yksityinen repositorio, jonka pitäisi vastaanottaa se. Virhe on antaa toisen työn rakentaa uudelleen haarasta ja kutsua tulosta samaksi julkaisuksi. Siirrä tiedosto, joka testattiin, nimeä se tiivisteen mukaan ja pidä latauksen tunnistetiedot sisäpuolella. Alla oleva kuvaus seuraa yhtä artefaktia julkisesta CI-ajurista sisäiselle julkaisijalle.

Rakenna siellä, missä lähdekoodi jo on

Aja build työssä, jolla on jo lähdekoodi, työkaluketju ja testisarja. Mikään yksityisessä repositoriossa ei vaadi, että tuo työ ulottuu siihen. Asenna buildin frontend ympäristöön, jota projekti jo käyttää, ja tuota sitten molemmat jakelumuodot, jos projekti toimittaa molemmat.

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

Pidä tuloste hakemisto pienenä ja kertakäyttöisenä. Ainoa eteenpäin kannettava asia on ne tiedostot, jotka seuraava työ julkaisee, sekä niiden hashit. Kaikki muu, myös virtuaaliympäristöt ja välimuistit, voidaan rakentaa uudelleen tallennetusta lähdekoodin revisiosta. Hoikka artefakti on myös helpompi tarkastaa, koska jokainen sen tiedosto on tiedosto, jonka joku voi tutkia.

Kirjaa, mikä ne tuotti: paketin nimi ja versio tiedostonimistä, lähdekoodin revisio ja työnkulun ajo, joka ne loi. Pelkkä versiomerkkijono ei yksilöi tiedostoa, koska sama versio voidaan rakentaa kahdesti eri commiteista. Kirjoita revisio tiedostonimien viereen artefaktin kuvaukseen ja käsittele sitä kirjausta osana luovutusta.

Siirrä tavuja, älä ohjeita rakentaa uudelleen

Toinen build on toinen tuote. Aikaleimat, mukana tulevat riippuvuudet ja työkaluversiot voivat kaikki muuttaa tavuja, joten uudelleenrakennus tarvitsee omat testinäyttönsä ja oman tarkastuksensa. Vie sen sijaan tarkastetut tiedostot eteenpäin.

Lataa jakelutiedostot CI-alustasi tarjoamaan artefaktivarastoon ja anna sisäiselle työlle viittaus juuri siihen artefaktiin haaran nimen sijaan.

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

Jos alustasi tukee allekirjoitettua alkuperää, pyydä sitä todistamaan artefakti ja myöhemmin vahvistamaan odotettu repositorio, työnkulku ja lähdekoodin revisio. GitHubin attestointidokumentaatio kuvaa tuon muotoisia väitteitä. Voimassa oleva allekirjoitus on todiste alkuperästä, ei haavoittuvuusskannaus eikä valtuutuspäätös.

Vahvista sisäpuolella ennen latausta

Sisäinen työ alkaa tarkistamalla, että vastaanotettu tiedosto on se tiedosto, joka hyväksyttiin. Vertaa tiivisteitä build-työn kirjaukseen, älä arvoon, joka on laskettu uudelleen siitä, mitä saapui.

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

Lue sitten metatiedot. Paketin nimen, version ja ilmoitettujen riippuvuuksien pitäisi vastata tarkastusta, jonka hyväksyit. Wheel, jonka nimi näyttää oikealta mutta jonka riippuvuuksien kiinnitykset ovat muuttuneet, on toinen paketti samalla etiketillä. Jos metatiedot ovat liikkuneet, käsittele artefakti hyväksymättömänä ja selvitä, mikä build sen tuotti.

Jos tiivisteet eivät täsmää, pysähdy. Älä lataa äläkä korjaa tiedostoa rakentamalla sitä uudelleen paikallaan; se pyyhkii pois todisteen siitä, että jokin muuttui siirrossa. Epätäsmällisyys tarkoittaa, että artefaktivarasto, latausvaihe tai kirjaus on väärin, ja jokainen niistä ansaitsee selityksen ennen julkaisun julkaisemista.

Käsittele kaksoisversion vastaus

Yksityiset repositoriot yleensä kieltäytyvät korvaamasta olemassa olevaa versiota, ja se kieltäytyminen on ominaisuus. Kun lataus epäonnistuu, koska versio on olemassa, tutki repositorion kirjausta kyseisestä versiosta ja vertaa sen sisältämiä tiedostoja tiivisteisiin, jotka aioit julkaista.

Olemassa oleva versio voi tarkoittaa, että aiempi lataus onnistui ja vastaus katosi, tai että joku julkaisi eri sisältöä samalla numerolla.

Älä poista versiota äläkä keksi uutta numeroa päästäksesi virheen ohi. Päätä julkaisun omistajan kanssa, onko tallennettu sisältö hyväksyttävää, ja kirjaa sitten tulos. Jos sisältö eroaa, sinulla on versiointiongelma, ei pipeline-ongelma.

Pidä latauksen tunnistetiedot yhdellä puolella

Vain sisäinen julkaisija tarvitsee repositorion tunnistetiedot, ja vain latauksen keston ajan. Rajaa token kohderepositorioon ja lataustoimintoihin, pidä se sisäisen järjestelmän salaisuusvarastossa ja jätä se kokonaan build-työn ulkopuolelle. Jos build-työ voi julkaista, silloin kuka tahansa buildin voi muuttaa voi julkaista.

Rajoita myös sitä, mitkä sisäiset työnkulut saavat käynnistää julkaisijan. Manuaalinen liipaisin vaaditulla hyväksynnällä on kohtuullinen oletus julkaisuille; push mihin tahansa haaraan ei ole.

Valmiin julkaisun pitäisi jättää kolme asiaa taakseen: jakelutiedostot, niiden tiivisteet lähdekoodin revision kanssa ja repositorion kirjaus, joka näyttää saman version.