Baut e Python-Wheel ausserhalb vum Netz an publizéiert et dobannen

Dir hutt schonn e Build-Job, deen e Wheel produzéiert, an e private Repository, dat en erhalte soll. De Feeler ass, en zweete Job aus engem Branch nei bauen ze loossen an d'Resultat déiselwecht Verëffentlechung ze nennen. Verréckelt d'Datei, déi getest gouf, nennt se nom Digest a behält d'Upload-Accèsdaten dobannen. D'Uleedung hei drënner verfollegt een Artefakt vun engem ëffentleche CI-Runner bis bei en internen Editeur.

Baut do, wou de Quellcode schonn ass

Féiert de Build an deem Job aus, deen de Quellcode, d'Toolchain an d'Test-Suite schonn huet. Naischt um private Repository verlaangt, datt deen Job et erreecht. Installéiert de Build-Frontend an Ëmfeld, dat de Projet schonn benotzt, a produzéiert dann déi zwou Distributiounsformater, wann de Projet se allebéid liwwert.

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

Hält den Ausgab-Repertoire kleng a fir eemol. Nëmmen d'Dateie vum nächste Job an hir Hashe si wäert, weidergefreecht ze ginn. Alles anescht, och virtuell Ëmfelder a Caches, ka vun der festgehalener Quellrevisioun nei gebaut ginn. En dënnen Artefakt ass och méi einfach z'iwwerpréiwen, well all Datei dran eng Datei ass, déi een anneren inspectéiere kann.

Hält fest, wat se produzéiert huet: de Pakname an d'Versioun aus den Dateinimm, d'Quellrevisioun an de Workflow-Laf, deen se gemaach huet. Eng Versiounszeecheketten eleng identifizéiert keng Datei, well déiselwecht Versioun zweemol aus verschidden Commit'e gebaut ka ginn. Schreift d'Revisioun nieft den Dateinimm an der Artefakt-Beschreiwung a behandelt dës Opzeechnung als Deel vun der Iwwerreechung.

Bréngt Bytes, net Instruktiounen zum Neibauen

En zweeten Build ass en zweete Produkt. Zäitstempel, gebëndelt Ofhängegkeeten a Tool-Versioune kënnen d'Bytes änneren, dofir brauch e Neibau seng eegen Testbeweiser a seng eegen Iwwerpréiwung. Promoteiert amplaz déi gepréift Dateien.

Luet d'Distributiounsdateien an de Artefakt-Späicher erop, deen är CI-Plattform ubitt, a gitt dem internen Job eng Referenz op dee spezifeschen Artefakt amplaz op en Branch-Numm.

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

Wann är Plattform ënnerschriwwen Hierkonft ënnerstëtzt, frot se, den Artefakt ze attestéieren an duerno dee erwaarde Repository, Workflow an d'Quellrevisioun ze verifizéieren. Dem GitHub seng Dokumentatioun zu Attestatiounen beschreift Aussoen an där Form. Eng gëlteg Ënnerschrëft ass en Hierkonftsbeweis, keen Schwachstelle-Scan an och keng Autorisatiounsentscheedung.

Verifizéiert dobannen ier Dir eroplued

Den internen Job fänkt domat un ze préiwen, ob déi empfaange Datei déi guttgeheescht Datei ass. Vergläicht d'Digeste mam festgehalene Stand vum Build-Job, net mat engem Wäert, dee aus deem nei berechent gouf, wat ukomm ass.

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

Liest dann d'Metadaten. De Pakname, d'Versioun an déi deklaréiert Ofhängegkeete sollten zu där Iwwerpréiwung passen, déi Dir guttgeheescht hutt. E Wheel, deem säin Numm richteg ausgesäit, awer deem seng Ofhängegkeets-Pins sech geännert hunn, ass en anere Pak mam selwechte Label. Wann d'Metadaten sech verréckelt hunn, behandelt den Artefakt als net guttgeheescht a fannt eraus, wéi ee Build en produzéiert huet.

Wann d'Digeste net passen, stoppt. Luet net erop a reparéiert d'Datei net, andeems Dir se op der Plaz nei baut; dat läscht de Beweis, datt sech ënnerwee eppes geännert huet. Eng Ofwäichung heescht, datt den Artefakt-Späicher, den Download-Schrëtt oder d'Opzeechnung falsch ass, an all eenzelt dovun verdéngt eng Erklärung, ier eng Verëffentlechung publizéiert gëtt.

Behandelt d'Äntwert op duebel Versiounen

Privat Repositoryen refuséieren normalerweis eng existéierend Versioun z'iwwerschreiwen, an dëse Refus ass eng Funktioun. Wann en Upload feelt, well d'Versioun existéiert, kuckt d'Opzeechnung vum Repository fir déi Versioun un a vergläicht d'Dateien, déi en hält, mat den Digeste, déi Dir publizéiere wëllt.

Eng existéierend Versioun kann heeschen, datt en fréieren Upload gelungen ass an d'Äntwert verluer gaart, oder datt een aneren Inhalt ënner der selwechter Nummer publizéiert huet.

Läscht d'Versioun net a erfënnt keng nei Nummer, fir de Feeler z'ëmgoen. Entscheet mam Verantwortleche vun der Verëffentlechung, ob den gespäicherten Inhalt akzeptabel ass, a schreift dann d'Resultat op. Wann den Inhalt änners ass, hutt Dir e Versiounsproblem, keen Pipeline-Problem.

Hält d'Upload-Accèsdaten op enger Säit

Nëmmen den internen Editeur brauch Repository-Accèsdaten, an dat just fir d'Dauer vum Upload. Beschränkt den Token op de Zil-Repository an op Upload-Operatiounen, hält en an de Geheimspäicher vum internen System a loosst en komplett aus dem Build-Job eraus. Wann de Build-Job publizéiere kann, da kann jiddereen, dee de Build änneren kann, publizéieren.

Beschränkt och, wéi eng intern Workflows den Editeur dierfe starten. En manuellen Ausléiser mat enger erfuerderter Genehmegung ass e vernünftegen Standard fir Verëffentlechungen; e Push op en beliebige Branch ass et net.

Déi fäerdeg Verëffentlechung soll dräi Saachen hannerloossen: d'Distributiounsdateien, hir Digeste mat der Quellrevisioun an eng Repository-Opzeechnung, déi déiselwecht Versioun weist.