Ein Python-Wheel außerhalb des Netzwerks bauen und drinnen veröffentlichen

Sie haben bereits einen Build-Job, der ein Wheel erzeugt, und ein privates Repository, das es erhalten soll. Der Fehler ist, einen zweiten Job aus einem Branch neu bauen zu lassen und das Ergebnis dieselbe Veröffentlichung zu nennen. Verschieben Sie die Datei, die getestet wurde, benennen Sie sie nach dem Digest, und halten Sie die Upload-Anmeldedaten drinnen. Die folgende Anleitung verfolgt ein Artefakt von einem öffentlichen CI-Runner bis zu einem internen Publisher.

Dort bauen, wo der Quellcode schon liegt

Führen Sie den Build in dem Job aus, der bereits den Quellcode, die Toolchain und die Testsuite hat. Nichts an einem privaten Repository verlangt, dass dieser Job es erreicht. Installieren Sie das Build-Frontend in der Umgebung, die das Projekt ohnehin nutzt, und erzeugen Sie dann beide Distributionsformate, wenn das Projekt beide ausliefert.

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

Halten Sie das Ausgabeverzeichnis klein und entbehrlich. Weiterzugeben lohnt sich nur, was der nächste Job veröffentlichen wird, plus die Hashes dazu. Alles andere, auch virtuelle Umgebungen und Caches, lässt sich aus der festgehaltenen Quellcode-Revision neu bauen. Ein schlankes Artefakt ist außerdem leichter zu prüfen, weil jede Datei darin eine Datei ist, die jemand ansehen kann.

Halten Sie fest, was sie erzeugt hat: Paketname und Version aus den Dateinamen, die Quellcode-Revision und der Workflow-Lauf, der sie hervorgebracht hat. Eine Versionszeichenkette allein identifiziert keine Datei, denn dieselbe Version lässt sich zweimal aus verschiedenen Commits bauen. Schreiben Sie die Revision neben die Dateinamen in die Artefaktbeschreibung und behandeln Sie diesen Eintrag als Teil der Übergabe.

Bytes weitergeben, nicht Anweisungen zum Neubauen

Ein zweiter Build ist ein zweites Produkt. Zeitstempel, gebündelte Abhängigkeiten und Tool-Versionen können die Bytes verändern, deshalb braucht ein Neubau eigene Testnachweise und eine eigene Prüfung. Befördern Sie stattdessen die geprüften Dateien.

Laden Sie die Distributionsdateien in den Artefaktspeicher hoch, den Ihre CI-Plattform bereitstellt, und geben Sie dem internen Job einen Verweis auf genau dieses Artefakt statt auf einen Branch-Namen.

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

Wenn Ihre Plattform signierte Herkunft unterstützt, lassen Sie das Artefakt attestieren und später das erwartete Repository, den Workflow und die Quellcode-Revision prüfen. GitHubs Dokumentation zu Attestierungen beschreibt Aussagen dieser Form. Eine gültige Signatur ist ein Herkunftsnachweis, kein Schwachstellenscan und keine Autorisierungsentscheidung.

Drinnen prüfen, bevor hochgeladen wird

Der interne Job beginnt damit zu prüfen, ob die empfangene Datei die freigegebene Datei ist. Vergleichen Sie die Digests mit dem Eintrag aus dem Build-Job, nicht mit einem Wert, der aus dem neu berechnet wurde, was angekommen ist.

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

Lesen Sie dann die Metadaten. Paketname, Version und die deklarierten Abhängigkeiten sollten zur freigegebenen Prüfung passen. Ein Wheel, dessen Name richtig aussieht, dessen Abhängigkeits-Pins sich aber geändert haben, ist ein anderes Paket mit demselben Etikett. Wenn sich die Metadaten verschoben haben, behandeln Sie das Artefakt als nicht freigegeben und finden Sie heraus, welcher Build es erzeugt hat.

Wenn die Digests nicht übereinstimmen, halten Sie an. Laden Sie nicht hoch und reparieren Sie die Datei nicht, indem Sie sie an Ort und Stelle neu bauen; das löscht den Beleg dafür, dass sich unterwegs etwas verändert hat. Eine Abweichung bedeutet, dass der Artefaktspeicher, der Download-Schritt oder der Eintrag falsch ist, und jedes davon verdient eine Erklärung, bevor eine Veröffentlichung erscheint.

Die Antwort auf doppelte Versionen behandeln

Private Repositories verweigern normalerweise das Überschreiben einer vorhandenen Version, und diese Verweigerung ist eine Funktion. Wenn ein Upload fehlschlägt, weil die Version existiert, sehen Sie sich den Eintrag des Repositories zu dieser Version an und vergleichen Sie die dortigen Dateien mit den Digests, die Sie veröffentlichen wollten.

Eine vorhandene Version kann bedeuten, dass ein früherer Upload erfolgreich war und die Antwort verloren ging, oder dass jemand anderen Inhalt unter derselben Nummer veröffentlicht hat.

Löschen Sie die Version nicht und erfinden Sie keine neue Nummer, um den Fehler zu umgehen. Entscheiden Sie mit dem Verantwortlichen der Veröffentlichung, ob der gespeicherte Inhalt akzeptabel ist, und halten Sie das Ergebnis fest. Wenn der Inhalt abweicht, haben Sie ein Versionsproblem, kein Pipeline-Problem.

Upload-Anmeldedaten auf einer Seite halten

Nur der interne Publisher braucht Repository-Anmeldedaten, und nur für die Dauer des Uploads. Beschränken Sie das Token auf das Ziel-Repository und auf Upload-Operationen, bewahren Sie es im Secret Store des internen Systems auf und halten Sie es vollständig aus dem Build-Job heraus. Wenn der Build-Job veröffentlichen kann, kann jeder veröffentlichen, der den Build ändern kann.

Beschränken Sie außerdem, welche internen Workflows den Publisher starten dürfen. Ein manueller Auslöser mit erforderlicher Freigabe ist eine vernünftige Voreinstellung für Veröffentlichungen; ein Push auf einen beliebigen Branch ist es nicht.

Die fertige Veröffentlichung sollte drei Dinge hinterlassen: die Distributionsdateien, ihre Digests samt Quellcode-Revision und einen Repository-Eintrag, der dieselbe Version zeigt.