Építs Python wheel csomagot a hálózaton kívül, és publikáld belül

Már van egy build-feladatod, amely wheel csomagot állít elő, és egy privát tároló, amelynek fogadnia kellene. A hiba az, hogy egy második feladat újraépít egy ágról, és az eredményt ugyanannak a kiadásnak nevezi. Mozgasd tovább a tesztelt fájlt, nevezd el a kivonat alapján, és tartsd a feltöltési hitelesítő adatot belül. Az alábbi végigvezetés egyetlen artefaktumot követ egy nyilvános CI-futtatótól egy belső publikálóig.

Ott építs, ahol a forráskód már van

Futtasd a buildet abban a feladatban, amelynek már megvan a forráskód, az eszközlánc és a tesztsor. A privát tárolóval kapcsolatban semmi sem írja elő, hogy annak a feladatnak el kell érnie. Telepítsd a build frontendet abba a környezetbe, amelyet a projekt már használ, majd állítsd elő mindkét disztribúciós formátumot, ha a projekt mindkettőt szállítja.

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

Tartsd a kimeneti könyvtárat kicsinek és egyszer használatosnak. Csak azokat a fájlokat érdemes továbbvinni, amelyeket a következő feladat publikálni fog, valamint a hash-eiket. Minden más, a virtuális környezeteket és gyorsítótárakat is beleértve, újraépíthető a rögzített forrásváltozatból. A karcsú artefaktum áttekintése is könnyebb, mert minden benne lévő fájl olyan fájl, amelyet valaki megvizsgálhat.

Rögzítsd, mi állította elő őket: a csomagnév és a verzió a fájlnevekből, a forrásváltozat, és az a workflow-futtatás, amely létrehozta őket. Egy verziószöveg önmagában nem azonosít egy fájlt, mert ugyanaz a verzió kétszer is megépíthető különböző commitokból. Írd a változatot a fájlnevek mellé az artefaktum leírásába, és kezeld ezt a feljegyzést az átadás részének.

Bájtokat mozgass, ne újraépítési utasításokat

A második build második termék. Az időbélyegek, a beágyazott függőségek és az eszközverziók mind megváltoztathatják a bájtokat, ezért az újraépítésnek saját tesztbizonyítékra és saját átvizsgálásra van szüksége. Inkább az átvizsgált fájlokat léptesd előre.

Töltsd fel a disztribúciós fájlokat a CI-platformod által biztosított artefaktumtárba, és adj a belső feladatnak hivatkozást arra a konkrét artefaktumra, nem egy ág nevére.

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

Ha a platformod támogatja az aláírt eredetigazolást, kérdezd meg tőle az artefaktum igazolását, majd később az elvárt tároló, workflow és forrásváltozat ellenőrzését. A GitHub igazolási dokumentációja ilyen formájú állításokat ír le. Az érvényes aláírás eredetigazolás, nem sebezhetőségi vizsgálat, és nem engedélyezési döntés.

Belül ellenőrizd, mielőtt feltöltesz

A belső feladat azzal kezdődik, hogy ellenőrzi: a kapott fájl az a fájl-e, amelyet jóváhagytak. Hasonlítsd össze a kivonatokat a build-feladat feljegyzésével, ne egy olyan értékkel, amelyet abból számoltak újra, ami megérkezett.

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

Ezután olvasd el a metaadatokat. A csomagnévnek, a verziónak és a megadott függőségeknek meg kell felelniük annak az átvizsgálásnak, amelyet jóváhagytál. Az a wheel, amelynek a neve helyesnek tűnik, de a függőségi rögzítései megváltoztak, egy másik csomag ugyanazzal a címkével. Ha a metaadatok elmozdultak, kezeld az artefaktumot nem jóváhagyottként, és derítsd ki, melyik build állította elő.

Ha a kivonatok nem egyeznek, állj meg. Ne tölts fel, és ne javítsd a fájlt a helyszíni újraépítéssel; az kitörli annak bizonyítékát, hogy valami megváltozott az átvitel során. Az eltérés azt jelenti, hogy az artefaktumtár, a letöltési lépés vagy a feljegyzés hibás, és mindegyik magyarázatot érdemel, mielőtt egy kiadás megjelenik.

Kezeld az ismétlődő verzió válaszát

A privát tárolók általában megtagadják egy létező verzió felülírását, és ez a megtagadás egy funkció. Amikor egy feltöltés azért hiúsul meg, mert a verzió létezik, vizsgáld meg a tároló feljegyzését arról a verzióról, és hasonlítsd össze a benne tartott fájlokat a kivonatokkal, amelyeket publikálni akartál.

Egy létező verzió jelentheti azt, hogy egy korábbi feltöltés sikerült, és a válasz elveszett, vagy azt, hogy valaki más tartalmat publikált ugyanazon szám alatt.

Ne töröld a verziót, és ne találj ki új számot a hiba megkerülésére. Döntsd el a kiadás tulajdonosával, hogy a tárolt tartalom elfogadható-e, majd rögzítsd az eredményt. Ha a tartalom eltér, verziózási problémád van, nem pipeline-problémád.

Tartsd a feltöltési hitelesítő adatot az egyik oldalon

Csak a belső publikálónak van szüksége tárolói hitelesítő adatokra, és csak a feltöltés idejére. Szűkítsd a tokent a cél-tárolóra és a feltöltési műveletekre, tartsd a belső rendszer titoktárában, és hagyd teljesen a build-feladaton kívül. Ha a build-feladat publikálhat, akkor bárki publikálhat, aki a buildet módosíthatja.

Korlátozd azt is, mely belső workflow-k indíthatják a publikálót. A kötelező jóváhagyással járó kézi indítás ésszerű alapértelmezés a kiadásokhoz; bármely ágra történő push nem az.

A kész kiadásnak három dolgot kell maga után hagynia: a disztribúciós fájlokat, a kivonataikat a forrásváltozattal együtt, és egy tárolói feljegyzést, amely ugyanazt a verziót mutatja.