publish-helm-chart: charts-url nur noch bis /api/packages, Owner aus dem Repository #63

New Issue

2026-09-30T20:45:59+02:00

jlab-bot commented

2026-09-30 20:45:59 +02:00

publish-helm-chart.yml soll die Ziel-URL anders zusammensetzen: Das 1Password-Feld trägt künftig nur noch die Basis bis /api/packages, der Owner kommt aus dem Repository.

Dieser Text ist der freigegebene Plan; ein eigener Plan-Kommentar entfällt.

Heute

charts-url trägt die vollständige Registry-URL, der Workflow hängt den Endpunkt an (Zeile 142):

"${REGISTRY_CHARTS_URL%/}/api/charts"

Künftig

op://GitHub-Actions/jlab-registry-access/charts-url  =  https://sub.domain.tld/api/packages
Ziel                                                 =  <basis>/<owner>/helm/api/charts

Der Owner kommt aus ${{ github.repository_owner }}, nicht aus einer festen Vorgabe und nicht aus einem Wert je Aufrufer.

Warum das trägt, und warum es die sauberste der drei erwogenen Varianten ist:

Nichts zu pflegen: Die 26 dünnen publish-<chart>.yml bleiben unverändert, und im Repo steht weiterhin kein Wert, der auf die Registry zeigt — auch das Pfadsegment nicht.
Das zweite Chart der Instanz (suer-configurator, Owner suer) bekommt damit automatisch das richtige Ziel, ohne zweite Vorgabe. Die Registry hat genau diese zwei Owner (siehe renovate.json5 in cluster-config).
Der Einwand gegen diese Variante — auf dem github.com-Spiegel heißt der Owner anders — greift nicht: Dort sind Actions abgeschaltet, der Publish läuft nie. Und liefe er doch, zeigte die abgeleitete URL auf einen Owner, den die Instanz nicht kennt: HTTP 404, laut, nicht stillschweigend am falschen Ziel.

Wächter, die dazugehören

Die alte Form muss laut scheitern, nicht rätselhaft. Enthält charts-url noch /helm, den Owner oder ein angehängtes /api/charts, bricht der Workflow mit einer Meldung ab, die sagt, was im Tresor zu ändern ist. Ohne diesen Wächter wäre die einzige Rückmeldung ein 404 gegen eine maskierte URL.
Der abgeleitete Owner wird geprüft: nicht leer, und nur unbedenkliche Zeichen. Ein leerer Wert ergäbe <basis>//helm/api/charts und damit wieder nur einen 404.
Alles Bestehende bleibt, weil jede dieser Eigenschaften einmal bezahlt wurde: die :?-Wächter je Feld, die Leerzeichen-Prüfung an den Zugangsdaten (curl --config schneidet unquotierte Werte am ersten Leerzeichen ab), das Maskieren des Hosts, der gebaute Dateiname statt eines Globs, und --fail-with-body, ohne das ein 401 als Erfolg durchginge.

Was gemessen werden muss, nicht angenommen

Ist github.repository_owner auf dieser Forge überhaupt gefüllt? Die Variante hängt vollständig daran. Gitea zielt auf Kompatibilität, aber das ist eine Behauptung über eine fremde Implementierung — zu belegen mit einem vorübergehenden Schritt in einem Workflow, der auf einen PR läuft, der beobachteten Ausgabe im Lauf, und anschließendem Entfernen des Schritts. Der beobachtete Wert gehört in die PR-Beschreibung.

Umstieg: harter Schnitt

Secret und Workflow müssen zusammenpassen; beide Fehlpaarungen scheitern laut (404), keine veröffentlicht am falschen Ort.

Reihenfolge: Der Betreuer ändert den Tresor-Eintrag, dann wird gemergt. Der Merge selbst löst keinen Publish aus, weil dieser PR kein Chart-Verzeichnis anfasst — die neue Form ist damit bis zur nächsten Chart-Änderung unbelegt.

Deshalb der End-zu-End-Nachweis über einen manuellen Lauf: publish-helm-chart.yml hat workflow_dispatch. Die Registry nimmt das erneute Hochladen einer bereits veröffentlichten Version an (HTTP 201) und ersetzt das Artefakt — ein Dispatch für ein beliebiges Chart ist also ein gefahrloser Test des ganzen Pfades. Das gehört als Handlungsanweisung in die PR-Beschreibung, denn auslösen kann es nur der Betreuer: Das Bot-Konto hat kein Schreibrecht am Repository.

Dokumentation

README, Abschnitt zu publish-helm-chart.yml: Der Satz „the workflow appends /api/charts to charts-url" wird falsch und ist zu ersetzen. Die Aussage „No registry address ever appears in this repository" bleibt gültig — sie gehört mit der neuen Begründung versehen, dass auch der Owner nicht im Repo steht, sondern abgeleitet wird.

Ebenso die Wiki-Seite CI-CD, Abschnitt „Publishing".

Umfang

Ein Workflow, README, eine Wiki-Seite. Kein Chart: kein Versionsschritt, kein Install-Test, keine Veröffentlichung durch diesen PR.

`publish-helm-chart.yml` soll die Ziel-URL anders zusammensetzen: Das 1Password-Feld trägt künftig nur noch die **Basis bis `/api/packages`**, der **Owner** kommt aus dem Repository. Dieser Text ist der freigegebene Plan; ein eigener Plan-Kommentar entfällt. ## Heute `charts-url` trägt die vollständige Registry-URL, der Workflow hängt den Endpunkt an (Zeile 142): ``` "${REGISTRY_CHARTS_URL%/}/api/charts" ``` ## Künftig ``` op://GitHub-Actions/jlab-registry-access/charts-url = https://sub.domain.tld/api/packages Ziel = <basis>/<owner>/helm/api/charts ``` Der Owner kommt aus **`${{ github.repository_owner }}`**, nicht aus einer festen Vorgabe und nicht aus einem Wert je Aufrufer. **Warum das trägt, und warum es die sauberste der drei erwogenen Varianten ist:** - Nichts zu pflegen: Die 26 dünnen `publish-<chart>.yml` bleiben unverändert, und im Repo steht weiterhin **kein** Wert, der auf die Registry zeigt — auch das Pfadsegment nicht. - Das zweite Chart der Instanz (`suer-configurator`, Owner `suer`) bekommt damit automatisch das richtige Ziel, ohne zweite Vorgabe. Die Registry hat genau diese zwei Owner (siehe `renovate.json5` in cluster-config). - Der Einwand gegen diese Variante — auf dem github.com-Spiegel heißt der Owner anders — greift nicht: Dort sind Actions **abgeschaltet**, der Publish läuft nie. Und liefe er doch, zeigte die abgeleitete URL auf einen Owner, den die Instanz nicht kennt: HTTP 404, laut, nicht stillschweigend am falschen Ziel. ## Wächter, die dazugehören 1. **Die alte Form muss laut scheitern, nicht rätselhaft.** Enthält `charts-url` noch `/helm`, den Owner oder ein angehängtes `/api/charts`, bricht der Workflow mit einer Meldung ab, die sagt, was im Tresor zu ändern ist. Ohne diesen Wächter wäre die einzige Rückmeldung ein 404 gegen eine maskierte URL. 2. **Der abgeleitete Owner wird geprüft:** nicht leer, und nur unbedenkliche Zeichen. Ein leerer Wert ergäbe `<basis>//helm/api/charts` und damit wieder nur einen 404. 3. **Alles Bestehende bleibt**, weil jede dieser Eigenschaften einmal bezahlt wurde: die `:?`-Wächter je Feld, die Leerzeichen-Prüfung an den Zugangsdaten (`curl --config` schneidet unquotierte Werte am ersten Leerzeichen ab), das Maskieren des Hosts, der **gebaute** Dateiname statt eines Globs, und `--fail-with-body`, ohne das ein 401 als Erfolg durchginge. ## Was gemessen werden muss, nicht angenommen **Ist `github.repository_owner` auf dieser Forge überhaupt gefüllt?** Die Variante hängt vollständig daran. Gitea zielt auf Kompatibilität, aber das ist eine Behauptung über eine fremde Implementierung — zu belegen mit einem **vorübergehenden** Schritt in einem Workflow, der auf einen PR läuft, der beobachteten Ausgabe im Lauf, und anschließendem Entfernen des Schritts. Der beobachtete Wert gehört in die PR-Beschreibung. ## Umstieg: harter Schnitt Secret und Workflow müssen zusammenpassen; beide Fehlpaarungen scheitern laut (404), keine veröffentlicht am falschen Ort. Reihenfolge: Der Betreuer ändert den Tresor-Eintrag, dann wird gemergt. **Der Merge selbst löst keinen Publish aus**, weil dieser PR kein Chart-Verzeichnis anfasst — die neue Form ist damit bis zur nächsten Chart-Änderung unbelegt. **Deshalb der End-zu-End-Nachweis über einen manuellen Lauf:** `publish-helm-chart.yml` hat `workflow_dispatch`. Die Registry nimmt das erneute Hochladen einer bereits veröffentlichten Version an (HTTP 201) und ersetzt das Artefakt — ein Dispatch für ein beliebiges Chart ist also ein gefahrloser Test des ganzen Pfades. Das gehört als Handlungsanweisung in die PR-Beschreibung, denn auslösen kann es nur der Betreuer: Das Bot-Konto hat kein Schreibrecht am Repository. ## Dokumentation README, Abschnitt zu `publish-helm-chart.yml`: Der Satz „the workflow appends `/api/charts` to `charts-url`" wird falsch und ist zu ersetzen. Die Aussage „No registry address ever appears in this repository" bleibt gültig — sie gehört mit der neuen Begründung versehen, dass auch der Owner nicht im Repo steht, sondern abgeleitet wird. Ebenso die Wiki-Seite `CI-CD`, Abschnitt „Publishing". ## Umfang Ein Workflow, README, eine Wiki-Seite. Kein Chart: kein Versionsschritt, kein Install-Test, keine Veröffentlichung durch diesen PR.

jlab-bot referenced a pull request that will close this issue

2026-09-30 20:50:27 +02:00

ci(publish): compose the registry URL from a base and the repository owner #64

jklein closed this issue

2026-09-30 20:54:21 +02:00

jlab-bot commented

2026-09-30 20:59:06 +02:00

Abschluss: Der Upload ist gelaufen, die neue Zusammensetzung trägt.

Damit ist der letzte Punkt geschlossen, der im PR als unbelegt markiert war — und es brauchte keinen manuellen Dispatch. Der Merge des Renovate-PR #59 hat urlaubsverwaltung/ angefasst und den Publish von selbst ausgelöst (Lauf 284, Push auf main).

Belegt am Artefakt, nicht am grünen Haken:

main:                version: 10.0.2+up6.14.0
Registry-Index:      10.0.2+up6.14.0  (neueste Fassung des Charts)

Die Ziel-URL wurde also aus der gekürzten Basis und dem abgeleiteten Owner gebaut, und die Registry hat das Paket angenommen. Zuvor war nur der Pfad geprüft (401 gegen 404, siehe Kommentar oben); jetzt ist der ganze Weg einmal gegangen.

Reihenfolge des Umstiegs hat wie geplant funktioniert: Tresor-Eintrag zuerst, dann Merge. Kein Lauf ist in das Fenster gefallen.

Abschluss: **Der Upload ist gelaufen, die neue Zusammensetzung trägt.** Damit ist der letzte Punkt geschlossen, der im PR als unbelegt markiert war — und es brauchte keinen manuellen Dispatch. Der Merge des Renovate-PR #59 hat `urlaubsverwaltung/` angefasst und den Publish von selbst ausgelöst (Lauf 284, Push auf `main`). Belegt am Artefakt, nicht am grünen Haken: ``` main: version: 10.0.2+up6.14.0 Registry-Index: 10.0.2+up6.14.0 (neueste Fassung des Charts) ``` Die Ziel-URL wurde also aus der gekürzten Basis und dem abgeleiteten Owner gebaut, und die Registry hat das Paket angenommen. Zuvor war nur der Pfad geprüft (401 gegen 404, siehe Kommentar oben); jetzt ist der ganze Weg einmal gegangen. Reihenfolge des Umstiegs hat wie geplant funktioniert: Tresor-Eintrag zuerst, dann Merge. Kein Lauf ist in das Fenster gefallen.

jlab-bot referenced this issue

2026-10-02 00:23:55 +02:00

publish-helm-chart nach workflow-util/pipelines auslagern - erster Plan #66

jklein referenced this issue from a commit

2026-10-02 01:05:05 +02:00

ci: publish charts through the shared block in workflow-util/pipelines

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: jlab-cluster/helm-charts#63