ci: publish charts through the shared block in workflow-util/pipelines #70
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: jlab-cluster/helm-charts#70
Reference in new issue
Block a user
Schritt 2 bis 4 der Reihenfolge am Issue. Der ausgelagerte Baustein ist gemergt
(
workflow-util/pipelines#7) und alsv3getaggt; dieser PR stellt dieAufrufe hier um und löscht die eigene Kopie.
Was sich ändert
Alle 25 Hüllen rufen jetzt den geteilten Baustein auf, an den Tag gebunden:
workflow_dispatchund derpush-Auslöser sind je Hülle unverändert. Geprüftnach der Umstellung: alle 25 haben beides, dieselbe Form, dieselben Pfade
(
<chart>/**), 16 Zeilen, keine Abweichung..github/workflows/publish-helm-chart.ymlist gelöscht, im selben Commitwie die Umstellung. Eine Hülle, die auf eine gelöschte Datei zeigt, und eine
verwaiste Datei, die niemand mehr aufruft, wären beide schlechter als der
Zustand vorher.
Eine Anmerkung zur Zahl: Es sind 25 Hüllen, nicht 26. Die 26. Datei im
publish-*.yml-Muster war der geteilte Workflow selbst. Issue und Plan nennen26; im README stand an einer Stelle noch 24. Beide Zahlen sind jetzt
nachgezählt und korrigiert.
Dokumentation
Der README-Abschnitt beschrieb
publish-helm-chart.ymlals Workflow diesesRepositories — das wäre ab diesem PR falsch. Er nennt jetzt, wo der Baustein
liegt, dass er an
@v3gebunden aufgerufen wird, und was jeder Aufruferbeisteuert: die Owner-Eingabe,
secrets: inherit, die VariableOP_CONNECT_HOSTundci/helm-dependencies.sh.Die Eigenschaften des Upload-Schritts sind nicht wiederholt, sondern
verlinkt — sie stehen jetzt im Wiki von
pipelines, und zwei Kopien einerErklärung heißt, dass eine von beiden irgendwann falsch ist. Mit dem
ausdrücklichen Zusatz, dass beim Umzug nichts davon verloren ging: Der
Shell-Körper des Upload-Schritts ist zeichengleich übernommen, abgesehen von
zwei Fehlermeldungen, die den Owner jetzt als Eingabe benennen.
Warum
install-test.ymlhier bleibt, steht im selben Abschnitt(Entscheidung 4 am Issue): verschweißt mit den
ci/-Fixtures, demAusschluss-Parser und der Chart-Matrix dieses Repositories. Ein Baustein, den
nur ein Repository benutzen kann, ist nicht geteilt, sondern verlagert — und ein
Tag zwischen uns und einer Datei, die wir oft ändern, kostet ohne Gegenwert.
Der Vermerk soll die Frage ein für alle Mal beantworten.
Wiki ist nachgezogen und schon gelandet (es gibt dort kein PR-Verfahren):
CI-CD, Abschnitt „Publishing", plusNew-ChartSchritt 1.Drei Stellen, die der Umzug nicht veraltet, sondern falsch gemacht hätte
Nicht im Plan, aber beim Umstellen gefunden — jede hätte stillschweigend in die
Irre geführt:
ci/helm-dependencies.shläuft in fünf Stellen, und eine davon war „vorhelm packageinpublish-helm-chart.yml". Es sind weiterhin fünf, abereine liegt jetzt jenseits der Repository-Grenze. Das macht das Skript zum
Vertragsbestandteil: Umbenennen oder Löschen bricht die Veröffentlichung von
einer Stelle aus, die unsere Diffs nicht mehr liest. Im README und im Wiki
so vermerkt.
install-test.ymlverwiesen aufpublish-helm-chart.ymlals Nachbardatei — einer davon auf eine Falle, diediese Datei „at length" dokumentiere. Genau diese Langform ist mit der
Löschung aus dem Repository verschwunden; die Kommentare nennen jetzt den
geteilten Baustein und dessen Wiki-Seite.
CLAUDE.md, „Creating a new chart", Schritt 1 nannte denwiederverwendbaren Workflow als unseren. Jetzt mit dem Hinweis, wo er liegt
und dass eine Hülle kopiert und nicht aus dem Gedächtnis geschrieben wird —
eine fehlende Owner-Eingabe fällt erst beim echten Publish auf.
Geprüft
uses-Pfad samt Tag,with-Schlüsselin der Reihenfolge
chart-name,registry-owner, der genaue Owner-Ausdruck,secrets: inherit,workflow_dispatchvorhanden,push-Zweigmain,push-Pfad<chart>/**, und dass das Chart-Verzeichnis existiert. 25 von 25ohne Befund, 25 verschiedene Charts.
install-test.yml,install-test-all-charts.yml,validate-charts.ymlundchange-app-version.ymlparsen weiterhin.ausdrücklich über den Umzug spricht.
actionlintgibt es in der Arbeitsumgebung nicht; die Dateien sind insoweitdurch Lesen geprüft.
Was dieser PR nicht beweisen kann
Deutlich, weil es der ganze Rest des Risikos ist. Drei Dinge zeigen sich erst im
ersten echten Lauf, und keine Prüfung hier ersetzt sie:
uses:auf dieser Gitea-Fassung — dass einuses:auf ein anderes Repository samt Tag überhaupt aufgelöst wird.vars.OP_CONNECT_HOSTin einem fremd aufgerufenen Workflowankommt. Die Variable ist gesetzt. Dass eine Repository-Variable des
Aufrufers den aufgerufenen Workflow erreicht, ist auf dieser Fassung nicht
gemessen — und boolesche Eingaben kommen hier nachweislich nicht an, also ist
die Annahme nicht umsonst zu haben. Der Wächter im Baustein scheitert in
diesem Fall laut und benennt die Variable, statt an einer leeren Adresse zu
scheitern.
Nachweis nach dem Merge — bitte nicht vergessen
Der Merge löst keinen Publish aus: Er fasst kein Chart-Verzeichnis an. Der
Nachweis ist deshalb ein manueller
workflow_dispatcheiner Hülle, etwa„Publish Outline Helm Chart". Die Registry ersetzt eine bereits
veröffentlichte Version bei erneutem Upload (HTTP 201, #160), der Test ist also
gefahrlos. Auslösen kann nur der Betreuer; das Bot-Konto kann keine Workflows
dispatchen.
Schlägt er fehl, ist der Rückweg kurz: Die Hüllen auf die alte Datei
zurückstellen, die aus der Historie dieses PRs wiederherstellen — der geteilte
Baustein und sein Tag bleiben davon unberührt.
Fixes #66
The reusable publish workflow now lives in workflow-util/pipelines and is called pinned to @v3. All 25 thin hulls switch over and our copy is deleted in the same commit: a hull pointing at a deleted file, or an orphaned file nobody calls, would both be worse than the state before. Each hull gains one line, registry-owner: ${{ github.repository_owner }}. The owner used to be derived inside the workflow (#63); as a required input without a default it is evaluated here, in the calling repository, where the value is measured. That is the house rule of pipelines - a shared block never guesses an owner segment - and it keeps the block free of any context semantics. The workflow_dispatch and push triggers of every hull are untouched; after the move the dispatch is the only way to trigger a publish by hand. The Connect host is no longer wired into the block. It reads the repository variable OP_CONNECT_HOST, which the maintainer has set, and fails in its first step naming the variable when it is empty. Documentation follows the same split as the code. The README entry no longer describes a workflow of this repository; it names where the block lives, what each caller owes it, and points at the publish-helm-chart page of that repository's wiki for the reasons behind the upload step, which are no longer ours to keep current. Nothing of them was lost in the move - the upload step's shell body went across unchanged apart from two error messages that name the owner as an input. Also corrected, because the move made them wrong rather than merely stale: - the helm-dependencies.sh entry still counted the local publish workflow among the five places it runs; it is still five, one of them now the shared block, which is why that block names the script as a prerequisite of its callers; - two comments in install-test.yml pointed at publish-helm-chart.yml as a sibling file, one of them for a trap it documented "at length" - that long form is now on the pipelines wiki, and the comments say so; - the hull count read 24, and reusable workflows with secrets: inherit are now confirmed to work across repositories too; - the chart-creation step in CLAUDE.md said the reusable workflow is ours. install-test.yml stays here, with the reason written down (decision 4 on the issue): it is reusable in form but welded to the ci/ fixtures, the exclusion parser and this repository's chart matrix. A block only one repository can use is not shared, only moved. The note is there so the question is not asked again. Fixes #66