Construiește un wheel Python în afara rețelei și publică-l în interior

Ai deja un job de build care produce un wheel și un repository privat care ar trebui să îl primească. Greșeala este să lași un al doilea job să reconstruiască dintr-o ramură și să numești rezultatul aceeași versiune. Mută fișierul care a fost testat, numește-l după amprentă și păstrează acreditarea de încărcare în interior. Ghidul de mai jos urmărește un artefact de la un runner CI public până la un publicator intern.

Construiește acolo unde se află deja codul sursă

Rulează build-ul în jobul care are deja codul sursă, lanțul de unelte și suita de teste. Nimic la un repository privat nu cere ca acel job să ajungă la el. Instalează frontend-ul de build în mediul pe care proiectul îl folosește deja, apoi produ ambele formate de distribuție dacă proiectul le livrează pe amândouă.

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

Ține directorul de ieșire mic și de unică folosință. Singurele lucruri care merită duse mai departe sunt fișierele pe care le va publica jobul următor, plus hash-urile lor. Orice altceva, inclusiv mediile virtuale și cache-urile, poate fi reconstruit din revizia de cod înregistrată. Un artefact suplu este și mai ușor de revizuit, pentru că fiecare fișier din el este un fișier pe care cineva îl poate inspecta.

Înregistrează ce le-a produs: numele pachetului și versiunea din numele fișierelor, revizia de cod și rularea de workflow care le-a creat. Un șir de versiune singur nu identifică un fișier, pentru că aceeași versiune poate fi construită de două ori din commit-uri diferite. Scrie revizia lângă numele fișierelor în descrierea artefactului și tratează acea înregistrare ca parte din predare.

Mută octeți, nu instrucțiuni de reconstruire

Un al doilea build este un al doilea produs. Marcajele de timp, dependențele incluse și versiunile de unelte pot schimba octeții, așa că o reconstruire are nevoie de propriile dovezi de test și de propria revizuire. Promovează în schimb fișierele revizuite.

Încarcă fișierele de distribuție în magazinul de artefacte oferit de platforma ta CI și dă jobului intern o referință la acel artefact anume, nu la un nume de ramură.

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

Dacă platforma ta suportă proveniență semnată, cere-i să ateste artefactul și apoi verifică repository-ul, workflow-ul și revizia de cod așteptate. Documentația de atestări GitHub descrie afirmații de această formă. O semnătură validă este dovadă de origine, nu o scanare de vulnerabilități și nu o decizie de autorizare.

Verifică în interior înainte de încărcare

Jobul intern începe prin a verifica dacă fișierul primit este fișierul care a fost aprobat. Compară amprentele cu înregistrarea din jobul de build, nu cu o valoare recalculată din ce a ajuns.

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

Apoi citește metadatele. Numele pachetului, versiunea și dependențele declarate ar trebui să corespundă revizuirii pe care ai aprobat-o. Un wheel al cărui nume pare corect, dar ale cărui fixări de dependențe s-au schimbat, este un alt pachet purtând aceeași etichetă. Dacă metadatele s-au mișcat, tratează artefactul ca neaprobat și află ce build l-a produs.

Dacă amprentele nu corespund, oprește-te. Nu încărca și nu repara fișierul reconstruindu-l la loc; asta șterge dovada că ceva s-a schimbat pe drum. O nepotrivire înseamnă că magazinul de artefacte, pasul de descărcare sau înregistrarea este greșită, iar fiecare dintre ele merită o explicație înainte ca o versiune să fie publicată.

Gestionează răspunsul de versiune duplicată

Repository-urile private de obicei refuză să suprascrie o versiune existentă, iar acest refuz este o facilitate. Când o încărcare eșuează pentru că versiunea există, inspectează înregistrarea repository-ului pentru acea versiune și compară fișierele pe care le ține cu amprentele pe care intenționai să le publici.

O versiune existentă poate însemna că o încărcare anterioară a reușit și răspunsul s-a pierdut, sau că cineva a publicat alt conținut sub același număr.

Nu șterge versiunea și nu inventa un număr nou ca să treci de eroare. Decide împreună cu proprietarul versiunii dacă conținutul stocat este acceptabil, apoi înregistrează rezultatul. Dacă conținutul diferă, ai o problemă de versionare, nu o problemă de pipeline.

Ține acreditarea de încărcare într-o singură parte

Doar publicatorul intern are nevoie de acreditări de repository și doar pe durata încărcării. Limitează tokenul la repository-ul țintă și la operațiile de încărcare, ține-l în seiful de secrete al sistemului intern și lasă-l complet în afara jobului de build. Dacă jobul de build poate publica, atunci oricine poate schimba build-ul poate publica.

Restrânge și care workflow-uri interne pot porni publicatorul. Un declanșator manual cu aprobare obligatorie este o alegere implicită rezonabilă pentru versiuni; un push către orice ramură nu este.

Versiunea finalizată ar trebui să lase în urmă trei lucruri: fișierele de distribuție, amprentele lor cu revizia de cod și o înregistrare a repository-ului care arată aceeași versiune.