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

New Issue

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

jlab-bot commented

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

publish-helm-chart.yml soll in das neue Sammel-Repository workflow-util/pipelines wandern, das genau dafür existiert: wiederverwendbare Bausteine, die nicht selbst ausgelöst, sondern über uses: aufgerufen werden.

Erster Plan mit den Entscheidungen, die vorher zu treffen sind. Noch kein freigegebener Umsetzungsplan.

Was dort schon gilt

Aus dem README von workflow-util/pipelines gelesen, nicht vermutet:

Workflows liegen unter .gitea/workflows/, nicht .github/workflows/.
Aufrufe binden immer an einen Tag, nie an @main, mit ausdrücklicher Begründung: Mit @main ändert jede Anpassung dort unangekündigt das Verhalten aller Projekte, und der Fehler zeigt sich dann, wo niemand etwas geändert hat.
secrets: inherit ist nötig, weil der Baustein OP_CONNECT_TOKEN aus dem aufrufenden Repository braucht.
OP_CONNECT_HOST ist dort eine Variable des aufrufenden Repositories, kein fest verdrahteter Wert.
Ein Eigentümer-Segment wird nie geraten: image-owner ist Pflichteingabe, „genau das war der Fehler des früher fest verdrahteten suer, unter dem die Images aller Projekte landeten".

Zwei gemessene Eigenheiten, die unsere Umsetzung bestimmen

1. Boolesche workflow_call-Eingaben kommen nicht an. Gemessen an Gitea 1.27.0 (dortiges Issue #4): Weder die Vorgabe noch ein ausdrücklich übergebenes push: true erreichte den aufgerufenen Workflow, inputs.push blieb leer — bei grünem Lauf. Alle string-Eingaben kamen im selben Lauf korrekt an. Für uns: Jede neue Eingabe ist type: string, auch wenn sie inhaltlich ein Schalter ist. Unsere beiden bestehenden Eingaben (chart-name, chart-location) sind bereits Strings.

2. Das Bot-Konto hat auf pipelines nur Leserecht (push: false, über die API geprüft). Weder ich noch ein Umsetzungs-Agent kann dort einen Zweig anlegen oder einen PR öffnen. Die Auslagerung ist damit zwangsläufig zweigeteilt.

Der Kern: der abgeleitete Owner muss eine Eingabe werden

Seit #63/#64 baut der Workflow die Ziel-URL aus der Basis im Tresor und ${{ github.repository_owner }}. Gemessen wurde dieser Wert in einem Lauf innerhalb von helm-charts: jlab-cluster.

Was er in einem aus einem fremden Repository aufgerufenen Workflow ergibt, ist unbekannt. In GitHub-Semantik bleibt der Kontext der des Aufrufers; ob Gitea das genauso hält, ist nicht gemessen — und messen können wir es erst, wenn in pipelines etwas liegt, was wir dort nicht anlegen dürfen.

Ergebnis wäre im schlechten Fall workflow-util statt jlab-cluster, also eine Veröffentlichung nach <basis>/workflow-util/helm/api/charts. Das scheitert laut (404, die Wächter aus #63 greifen), ist aber vermeidbar.

Deshalb: Der Owner wird eine Pflichteingabe vom Typ string, und der Aufrufer übergibt ${{ github.repository_owner }} — dort ist der Wert gemessen. Das deckt sich mit der Hausregel von pipelines, dass ein Eigentümer-Segment nie geraten wird, und es macht den Baustein für das suer-Chart gleich mitbenutzbar.

Was unverändert mitwandern muss

Jede Eigenschaft des Upload-Schritts ist einmal bezahlt worden und darf beim Umzug nicht verloren gehen:

curl --config - statt --user, damit die Zugangsdaten nicht in der Prozessliste stehen;
--fail-with-body, ohne das ein 401 als Erfolg durchgeht;
der gebaute Dateiname statt eines Globs;
die :?-Wächter je Feld, die Leerzeichen-Prüfung an den Zugangsdaten, das Maskieren des Hosts;
die drei Formwächter aus #63 (charts-url darf /helm, den Owner oder /api/charts nicht enthalten);
ci/helm-dependencies.sh vor helm package.

Zu entscheiden

Wer macht den pipelines-Teil? Entweder du legst die Datei dort an (ich liefere den fertigen Inhalt samt README-Abschnitt), oder das Bot-Konto bekommt Schreibrecht und ein Agent erledigt beide Seiten.
Welcher Tag? Die Tags dort sind repository-weit (v1, v2 betreffen beide docker-build-push.yml). Ein zusätzlicher Baustein ist additiv, braucht aber einen neuen Tag, damit unsere Aufrufe daran binden können — Vorschlag v3. Bestehende Aufrufer auf @v2 bleiben unberührt.
OP_CONNECT_HOST als Variable übernehmen? Unser Workflow hat den Host fest verdrahtet (https://op-connect.jk-dev.de). Die Hausregel dort ist eine Variable des aufrufenden Repositories. Dafür müsste in helm-charts die Variable gesetzt werden — das kann nur der Betreuer. Dafür spricht Einheitlichkeit, dagegen eine zusätzliche Voraussetzung, die beim Fehlen zu einem leeren Wert führt.
Was passiert mit install-test.yml? Auch das ist seit #52 ein wiederverwendbarer Workflow, aber er ist eng mit ci/-Fixtures dieses Repositories verzahnt und taugt nicht als geteilter Baustein. Vorschlag: bleibt hier, und das wird im README begründet, damit die Frage nicht erneut auftaucht.

Reihenfolge, wenn entschieden ist

pipelines: Workflow anlegen, README-Abschnitt ergänzen, Tag setzen.
helm-charts: die 26 dünnen publish-<chart>.yml auf uses: workflow-util/pipelines/.gitea/workflows/publish-helm-chart.yml@<tag> umstellen, registry-owner: ${{ github.repository_owner }} übergeben, secrets: inherit behalten, die eigene Kopie löschen, README und Wiki-Seite CI-CD nachziehen.
Nachweis: Der Merge löst nur dann einen Publish aus, wenn er ein Chart-Verzeichnis anfasst — tut er nicht. Also ein manueller workflow_dispatch für ein beliebiges Chart; die Registry ersetzt eine bereits veröffentlichte Version, der Test ist gefahrlos. Auslösen kann nur der Betreuer.

Zwischen Schritt 1 und 2 ist nichts kaputt: Solange die Aufrufe noch auf die lokale Datei zeigen, ändert der neue Baustein nichts.

`publish-helm-chart.yml` soll in das neue Sammel-Repository **`workflow-util/pipelines`** wandern, das genau dafür existiert: wiederverwendbare Bausteine, die nicht selbst ausgelöst, sondern über `uses:` aufgerufen werden. Erster Plan mit den Entscheidungen, die vorher zu treffen sind. Noch **kein** freigegebener Umsetzungsplan. ## Was dort schon gilt Aus dem README von `workflow-util/pipelines` gelesen, nicht vermutet: - Workflows liegen unter **`.gitea/workflows/`**, nicht `.github/workflows/`. - Aufrufe binden **immer an einen Tag**, nie an `@main`, mit ausdrücklicher Begründung: Mit `@main` ändert jede Anpassung dort unangekündigt das Verhalten aller Projekte, und der Fehler zeigt sich dann, wo niemand etwas geändert hat. - `secrets: inherit` ist nötig, weil der Baustein `OP_CONNECT_TOKEN` aus dem **aufrufenden** Repository braucht. - `OP_CONNECT_HOST` ist dort eine **Variable des aufrufenden Repositories**, kein fest verdrahteter Wert. - Ein Eigentümer-Segment wird **nie geraten**: `image-owner` ist Pflichteingabe, „genau das war der Fehler des früher fest verdrahteten `suer`, unter dem die Images aller Projekte landeten". ## Zwei gemessene Eigenheiten, die unsere Umsetzung bestimmen **1. Boolesche `workflow_call`-Eingaben kommen nicht an.** Gemessen an Gitea **1.27.0** (dortiges Issue #4): Weder die Vorgabe noch ein ausdrücklich übergebenes `push: true` erreichte den aufgerufenen Workflow, `inputs.push` blieb leer — **bei grünem Lauf**. Alle `string`-Eingaben kamen im selben Lauf korrekt an. Für uns: Jede neue Eingabe ist `type: string`, auch wenn sie inhaltlich ein Schalter ist. Unsere beiden bestehenden Eingaben (`chart-name`, `chart-location`) sind bereits Strings. **2. Das Bot-Konto hat auf `pipelines` nur Leserecht** (`push: false`, über die API geprüft). Weder ich noch ein Umsetzungs-Agent kann dort einen Zweig anlegen oder einen PR öffnen. Die Auslagerung ist damit zwangsläufig **zweigeteilt**. ## Der Kern: der abgeleitete Owner muss eine Eingabe werden Seit #63/#64 baut der Workflow die Ziel-URL aus der Basis im Tresor und **`${{ github.repository_owner }}`**. Gemessen wurde dieser Wert in einem Lauf **innerhalb** von helm-charts: `jlab-cluster`. **Was er in einem aus einem fremden Repository aufgerufenen Workflow ergibt, ist unbekannt.** In GitHub-Semantik bleibt der Kontext der des Aufrufers; ob Gitea das genauso hält, ist nicht gemessen — und messen können wir es erst, wenn in `pipelines` etwas liegt, was wir dort nicht anlegen dürfen. Ergebnis wäre im schlechten Fall `workflow-util` statt `jlab-cluster`, also eine Veröffentlichung nach `<basis>/workflow-util/helm/api/charts`. Das scheitert laut (404, die Wächter aus #63 greifen), ist aber vermeidbar. **Deshalb: Der Owner wird eine Pflichteingabe vom Typ `string`**, und der Aufrufer übergibt `${{ github.repository_owner }}` — dort ist der Wert gemessen. Das deckt sich mit der Hausregel von `pipelines`, dass ein Eigentümer-Segment nie geraten wird, und es macht den Baustein für das `suer`-Chart gleich mitbenutzbar. ## Was unverändert mitwandern muss Jede Eigenschaft des Upload-Schritts ist einmal bezahlt worden und darf beim Umzug nicht verloren gehen: - `curl --config -` statt `--user`, damit die Zugangsdaten nicht in der Prozessliste stehen; - `--fail-with-body`, ohne das ein 401 als Erfolg durchgeht; - der **gebaute** Dateiname statt eines Globs; - die `:?`-Wächter je Feld, die Leerzeichen-Prüfung an den Zugangsdaten, das Maskieren des Hosts; - die drei Formwächter aus #63 (`charts-url` darf `/helm`, den Owner oder `/api/charts` nicht enthalten); - `ci/helm-dependencies.sh` vor `helm package`. ## Zu entscheiden 1. **Wer macht den `pipelines`-Teil?** Entweder du legst die Datei dort an (ich liefere den fertigen Inhalt samt README-Abschnitt), oder das Bot-Konto bekommt Schreibrecht und ein Agent erledigt beide Seiten. 2. **Welcher Tag?** Die Tags dort sind repository-weit (`v1`, `v2` betreffen beide `docker-build-push.yml`). Ein zusätzlicher Baustein ist additiv, braucht aber einen neuen Tag, damit unsere Aufrufe daran binden können — Vorschlag `v3`. Bestehende Aufrufer auf `@v2` bleiben unberührt. 3. **`OP_CONNECT_HOST` als Variable übernehmen?** Unser Workflow hat den Host fest verdrahtet (`https://op-connect.jk-dev.de`). Die Hausregel dort ist eine Variable des aufrufenden Repositories. Dafür müsste in helm-charts die Variable gesetzt werden — das kann nur der Betreuer. Dafür spricht Einheitlichkeit, dagegen eine zusätzliche Voraussetzung, die beim Fehlen zu einem leeren Wert führt. 4. **Was passiert mit `install-test.yml`?** Auch das ist seit #52 ein wiederverwendbarer Workflow, aber er ist eng mit `ci/`-Fixtures dieses Repositories verzahnt und taugt nicht als geteilter Baustein. Vorschlag: bleibt hier, und das wird im README begründet, damit die Frage nicht erneut auftaucht. ## Reihenfolge, wenn entschieden ist 1. `pipelines`: Workflow anlegen, README-Abschnitt ergänzen, Tag setzen. 2. helm-charts: die 26 dünnen `publish-<chart>.yml` auf `uses: workflow-util/pipelines/.gitea/workflows/publish-helm-chart.yml@<tag>` umstellen, `registry-owner: ${{ github.repository_owner }}` übergeben, `secrets: inherit` behalten, die eigene Kopie löschen, README und Wiki-Seite `CI-CD` nachziehen. 3. **Nachweis:** Der Merge löst nur dann einen Publish aus, wenn er ein Chart-Verzeichnis anfasst — tut er nicht. Also ein manueller `workflow_dispatch` für ein beliebiges Chart; die Registry ersetzt eine bereits veröffentlichte Version, der Test ist gefahrlos. Auslösen kann nur der Betreuer. Zwischen Schritt 1 und 2 ist nichts kaputt: Solange die Aufrufe noch auf die lokale Datei zeigen, ändert der neue Baustein nichts.

jlab-bot commented

2026-10-02 00:29:58 +02:00

Zwei Korrekturen am Text oben, beide meine Fehler.

1. Das Bot-Konto hat Schreibrecht auf workflow-util/pipelines. Meine Angabe „nur Leserecht" stammt aus einer anonymen API-Abfrage — ohne Token meldet die Instanz naturgemäß pull: true, push: false. Mit Token ist der Zugang vorhanden, nachgewiesen am Auflisten der dortigen Issues. Die Auslagerung muss also nicht zweigeteilt werden; beide Hälften sind von hier machbar.

2. ${{ github.repository_owner }} löst den Owner des Repositories auf, in dem der Lauf stattfindet — also des aufrufenden, nicht des Repositories, in dem der Workflow liegt. Damit bliebe die Ableitung aus #64 auch nach dem Umzug korrekt, und mein Szenario „im schlechten Fall workflow-util" ist keine begründete Sorge, sondern war eine unnötige.

Was davon unberührt bleibt: Für den cross-repo-Fall auf dieser Gitea-Fassung ist der Wert nicht gemessen, nur dokumentiert beziehungsweise zugesichert. Ob daraus eine Pflichteingabe für den Owner folgt oder nicht, ist damit keine Sicherheitsfrage mehr, sondern eine Abwägung — und wird als solche entschieden.

Die vier Entscheidungen werden einzeln gestellt; die Antworten kommen anschließend als Kommentar hierher.

Zwei Korrekturen am Text oben, beide meine Fehler. **1. Das Bot-Konto hat Schreibrecht auf `workflow-util/pipelines`.** Meine Angabe „nur Leserecht" stammt aus einer **anonymen** API-Abfrage — ohne Token meldet die Instanz naturgemäß `pull: true, push: false`. Mit Token ist der Zugang vorhanden, nachgewiesen am Auflisten der dortigen Issues. Die Auslagerung muss also **nicht** zweigeteilt werden; beide Hälften sind von hier machbar. **2. `${{ github.repository_owner }}` löst den Owner des Repositories auf, in dem der Lauf stattfindet** — also des **aufrufenden**, nicht des Repositories, in dem der Workflow liegt. Damit bliebe die Ableitung aus #64 auch nach dem Umzug korrekt, und mein Szenario „im schlechten Fall `workflow-util`" ist keine begründete Sorge, sondern war eine unnötige. Was davon unberührt bleibt: Für den **cross-repo**-Fall auf dieser Gitea-Fassung ist der Wert nicht gemessen, nur dokumentiert beziehungsweise zugesichert. Ob daraus eine Pflichteingabe für den Owner folgt oder nicht, ist damit keine Sicherheitsfrage mehr, sondern eine Abwägung — und wird als solche entschieden. Die vier Entscheidungen werden einzeln gestellt; die Antworten kommen anschließend als Kommentar hierher.

jlab-bot commented

2026-10-02 00:32:49 +02:00

Entscheidungen (Betreuer, 2026-10-01). Damit ist der Plan freigegeben.

1. Der Owner wird Pflichteingabe

registry-owner, Typ string, ohne Vorgabe. Jede Hülle übergibt registry-owner: ${{ github.repository_owner }}.

Der Wert wird damit im Aufrufer ausgewertet, wo er gemessen ist (jlab-cluster, Lauf 282), und der Baustein hängt an keiner Kontext-Semantik — auch nicht an einer zugesicherten. Das deckt sich mit der Hausregel von pipelines, dass ein Eigentümer-Segment nie geraten wird, und macht den Baustein für das suer-Chart unmittelbar mitbenutzbar. Die zwei zusätzlichen Zeilen je Hülle sind der Preis; die Hüllen ändern sich wegen des uses:-Pfads ohnehin.

2. Tag `v3`, repository-weit

Folgt der vorhandenen Konvention. Aufrufer auf @v2 bleiben unberührt, weil ein zusätzlicher Baustein additiv ist.

Das gehört dort dokumentiert: Die Tag-Nummer bezeichnet den Zustand des Repositories, nicht die Version einer einzelnen Datei. Wer künftig docker-build-push.yml ändert, erhöht auf v4, und unser Aufruf auf @v3 bleibt gültig, obwohl sich an unserem Baustein nichts geändert hat. Ohne diesen Satz liest die nächste Person die Nummer als Dateiversion.

3. `OP_CONNECT_HOST` wird Variable des aufrufenden Repositories

Entspricht der dortigen Hausregel und ist für einen geteilten Baustein das Richtige: Er trägt dann nicht die Infrastruktur-Adresse eines einzelnen Mandanten. Dazu ein Wächter, der ein fehlendes oder leeres OP_CONNECT_HOST laut benennt, statt an einer leeren Adresse zu scheitern.

Voraussetzung, die nur der Betreuer setzen kann: Variable OP_CONNECT_HOST in den Einstellungen von helm-charts, Wert https://op-connect.jk-dev.de (der heute im Workflow verdrahtete Host).

4. `install-test.yml` bleibt hier

Mit begründetem Vermerk im README: Er ist mit den ci/-Fixtures, dem Ausschluss-Parser und der Chart-Matrix dieses Repositories verschweißt. Ein Baustein, den nur ein Repository benutzen kann, ist nicht geteilt, sondern verlagert. Der Vermerk soll verhindern, dass die Frage in einem halben Jahr erneut gestellt wird.

Reihenfolge, mit den Abhängigkeiten

PR in pipelines: .gitea/workflows/publish-helm-chart.yml plus README-Abschnitt (auf Deutsch, wie der Rest dort).
Betreuer merged diesen PR.
Tag v3 auf den Merge-Stand setzen.
PR in helm-charts: die 26 Hüllen auf @v3 umstellen samt registry-owner, eigene Kopie löschen, README und Wiki-Seite CI-CD nachziehen, Vermerk zu install-test.yml.
Betreuer setzt OP_CONNECT_HOST und merged.
Nachweis über einen manuellen workflow_dispatch für ein beliebiges Chart — die Registry ersetzt eine bereits veröffentlichte Version, der Test ist gefahrlos.

Schritt 4 darf vorbereitet werden, bevor 2 und 3 erledigt sind, aber nicht gemergt: Ohne Tag zeigt der Aufruf ins Leere, und ohne die Variable fehlt der Connect-Host. Zwischen 1 und 4 ist nichts kaputt, solange die Aufrufe noch auf die lokale Datei zeigen.

Entscheidungen (Betreuer, 2026-10-01). Damit ist der Plan freigegeben. ## 1. Der Owner wird Pflichteingabe `registry-owner`, Typ `string`, ohne Vorgabe. Jede Hülle übergibt `registry-owner: ${{ github.repository_owner }}`. Der Wert wird damit im **Aufrufer** ausgewertet, wo er gemessen ist (`jlab-cluster`, Lauf 282), und der Baustein hängt an keiner Kontext-Semantik — auch nicht an einer zugesicherten. Das deckt sich mit der Hausregel von `pipelines`, dass ein Eigentümer-Segment nie geraten wird, und macht den Baustein für das `suer`-Chart unmittelbar mitbenutzbar. Die zwei zusätzlichen Zeilen je Hülle sind der Preis; die Hüllen ändern sich wegen des `uses:`-Pfads ohnehin. ## 2. Tag `v3`, repository-weit Folgt der vorhandenen Konvention. Aufrufer auf `@v2` bleiben unberührt, weil ein zusätzlicher Baustein additiv ist. **Das gehört dort dokumentiert:** Die Tag-Nummer bezeichnet den Zustand des **Repositories**, nicht die Version einer einzelnen Datei. Wer künftig `docker-build-push.yml` ändert, erhöht auf `v4`, und unser Aufruf auf `@v3` bleibt gültig, obwohl sich an unserem Baustein nichts geändert hat. Ohne diesen Satz liest die nächste Person die Nummer als Dateiversion. ## 3. `OP_CONNECT_HOST` wird Variable des aufrufenden Repositories Entspricht der dortigen Hausregel und ist für einen geteilten Baustein das Richtige: Er trägt dann nicht die Infrastruktur-Adresse eines einzelnen Mandanten. Dazu ein Wächter, der ein fehlendes oder leeres `OP_CONNECT_HOST` **laut** benennt, statt an einer leeren Adresse zu scheitern. **Voraussetzung, die nur der Betreuer setzen kann:** Variable `OP_CONNECT_HOST` in den Einstellungen von `helm-charts`, Wert `https://op-connect.jk-dev.de` (der heute im Workflow verdrahtete Host). ## 4. `install-test.yml` bleibt hier Mit begründetem Vermerk im README: Er ist mit den `ci/`-Fixtures, dem Ausschluss-Parser und der Chart-Matrix dieses Repositories verschweißt. Ein Baustein, den nur ein Repository benutzen kann, ist nicht geteilt, sondern verlagert. Der Vermerk soll verhindern, dass die Frage in einem halben Jahr erneut gestellt wird. ## Reihenfolge, mit den Abhängigkeiten 1. **PR in `pipelines`**: `.gitea/workflows/publish-helm-chart.yml` plus README-Abschnitt (auf Deutsch, wie der Rest dort). 2. **Betreuer merged** diesen PR. 3. **Tag `v3`** auf den Merge-Stand setzen. 4. **PR in helm-charts**: die 26 Hüllen auf `@v3` umstellen samt `registry-owner`, eigene Kopie löschen, README und Wiki-Seite `CI-CD` nachziehen, Vermerk zu `install-test.yml`. 5. **Betreuer setzt `OP_CONNECT_HOST`** und merged. 6. **Nachweis** über einen manuellen `workflow_dispatch` für ein beliebiges Chart — die Registry ersetzt eine bereits veröffentlichte Version, der Test ist gefahrlos. Schritt 4 darf vorbereitet werden, bevor 2 und 3 erledigt sind, **aber nicht gemergt**: Ohne Tag zeigt der Aufruf ins Leere, und ohne die Variable fehlt der Connect-Host. Zwischen 1 und 4 ist nichts kaputt, solange die Aufrufe noch auf die lokale Datei zeigen.

jklein referenced this issue from a commit

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

Helm-Chart-Publish als geteilten Baustein aufnehmen

jlab-bot referenced this issue from workflow-util/pipelines

2026-10-02 00:40:13 +02:00

Helm-Chart-Publish als geteilten Baustein aufnehmen #7

jklein referenced this issue from a commit

2026-10-02 00:44:56 +02:00

README auf das Wiki verweisen

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