jlab-cluster/helm-charts
3
0 Fork 0
Code Issues 15 Pull Requests 3 Actions Packages Wiki Activity

_helpers.tpl: veralteter Satz "charts in this repo deliberately have no dependencies" in fast allen Charts #40

New Issue
Closed
opened 2026-09-22 22:19:19 +02:00 by jlab-bot · 2 comments
jlab-bot commented 2026-09-22 22:19:19 +02:00
Member
Copy link
Copy source

In den _helpers.tpl fast aller Charts steht im Kopfkommentar des Ressourcen-Helfers:

charts in this repo deliberately have no dependencies

Das stimmt seit #214 nicht mehr — Chart-Abhängigkeiten sind zulässig, ytdlp-web-player hat eine, und die Regel steht inzwischen als Richtlinie 14 in der README, nicht 13. Der Satz begründet damit eine Gestaltungsentscheidung (der Helfer wird kopiert statt geteilt) mit einer Regel, die es nicht mehr gibt.

Die Begründung selbst bleibt richtig, nur ihr Inhalt ist ein anderer: Geteilt würde der Helfer über ein Library-Chart, und das wäre ein zweites Artefakt zum Veröffentlichen, Versionieren und Ziehen — für etwa eine Änderung pro Jahr. Genau so steht es in searxng seit PR #38.

Bestandsaufnahme

Der Satz wurde bei der Arbeit an #18 in searxng korrigiert (Zeilen 22 und 172), weil das Chart dort ohnehin neu veröffentlicht wurde. In den übrigen Charts steht er weiterhin — gefunden wurde er unabhängig voneinander von mehreren Umsetzungs-Agenten in freesailarr, minecraft-router, urlaubsverwaltung, zipline, gotenberg, teamspeak-server, cyberchef, apache-tika, voucher-vault, bentopdf, rss-bridge und template-chart. Eine vollständige Zählung gehört an den Anfang der Umsetzung.

template-chart ist der wichtigste Einzelfall: Von dort kopiert ihn jedes neue Chart weiter.

Der Preis, und warum das Issue nicht trivial ist

Ein Kommentar in einem Chart-Verzeichnis ist trotzdem eine Änderung an diesem Chart. Nach der Regel dieses Repos heißt das Patch-Bump plus Veröffentlichung je Chart — also rund zwanzig Veröffentlichungen für eine reine Textkorrektur, jede davon mit Install-Test im PR.

Das ist der eigentliche Inhalt dieses Issues: zu entscheiden, ob das gerechtfertigt ist. Denkbare Wege:

  1. Alles in einem PR, rund zwanzig Patch-Bumps. Ehrlich und vollständig, aber ein großer Merge mit entsprechend langer Pipeline.
  2. Mitnehmen statt anstoßen: Der Satz wird nur in Charts korrigiert, die aus anderem Grund ohnehin angefasst werden — so wie es searxng gerade passiert ist. Kostet nichts extra, zieht sich aber über Monate, und in der Zwischenzeit widersprechen sich die Charts untereinander.
  3. Nur template-chart jetzt, damit wenigstens kein neues Chart den falschen Satz erbt, und der Rest nach Weg 2.

Zu beachten

Nicht nur den einen Satz suchen. In searxng stand dieselbe Behauptung zusätzlich in values.yaml und verwies dort auf die falsche Richtliniennummer. Wer das umsetzt, sollte nach der Aussage suchen, nicht nach dem Wortlaut.

Ebenfalls zu prüfen: .github/workflows/change-app-version.yml nennt für freesailarr weiterhin „nine images"; seit MediathekArr sind es zehn. Gleiche Fehlerklasse, andere Datei — dort ohne Versions- und Veröffentlichungskosten.

In den `_helpers.tpl` fast aller Charts steht im Kopfkommentar des Ressourcen-Helfers: > charts in this repo deliberately have no dependencies Das stimmt seit #214 nicht mehr — Chart-Abhängigkeiten sind zulässig, `ytdlp-web-player` hat eine, und die Regel steht inzwischen als Richtlinie **14** in der README, nicht 13. Der Satz begründet damit eine Gestaltungsentscheidung (der Helfer wird kopiert statt geteilt) mit einer Regel, die es nicht mehr gibt. Die Begründung selbst bleibt richtig, nur ihr Inhalt ist ein anderer: Geteilt würde der Helfer über ein Library-Chart, und das wäre ein zweites Artefakt zum Veröffentlichen, Versionieren und Ziehen — für etwa eine Änderung pro Jahr. Genau so steht es in `searxng` seit PR #38. ## Bestandsaufnahme Der Satz wurde bei der Arbeit an #18 in `searxng` korrigiert (Zeilen 22 und 172), weil das Chart dort ohnehin neu veröffentlicht wurde. In den übrigen Charts steht er weiterhin — gefunden wurde er unabhängig voneinander von mehreren Umsetzungs-Agenten in `freesailarr`, `minecraft-router`, `urlaubsverwaltung`, `zipline`, `gotenberg`, `teamspeak-server`, `cyberchef`, `apache-tika`, `voucher-vault`, `bentopdf`, `rss-bridge` und `template-chart`. Eine vollständige Zählung gehört an den Anfang der Umsetzung. `template-chart` ist der wichtigste Einzelfall: Von dort kopiert ihn jedes neue Chart weiter. ## Der Preis, und warum das Issue nicht trivial ist Ein Kommentar in einem Chart-Verzeichnis ist trotzdem eine Änderung an diesem Chart. Nach der Regel dieses Repos heißt das **Patch-Bump plus Veröffentlichung je Chart** — also rund zwanzig Veröffentlichungen für eine reine Textkorrektur, jede davon mit Install-Test im PR. Das ist der eigentliche Inhalt dieses Issues: zu entscheiden, ob das gerechtfertigt ist. Denkbare Wege: 1. **Alles in einem PR**, rund zwanzig Patch-Bumps. Ehrlich und vollständig, aber ein großer Merge mit entsprechend langer Pipeline. 2. **Mitnehmen statt anstoßen**: Der Satz wird nur in Charts korrigiert, die aus anderem Grund ohnehin angefasst werden — so wie es `searxng` gerade passiert ist. Kostet nichts extra, zieht sich aber über Monate, und in der Zwischenzeit widersprechen sich die Charts untereinander. 3. **Nur `template-chart` jetzt**, damit wenigstens kein neues Chart den falschen Satz erbt, und der Rest nach Weg 2. ## Zu beachten Nicht nur den einen Satz suchen. In `searxng` stand dieselbe Behauptung zusätzlich in `values.yaml` und verwies dort auf die falsche Richtliniennummer. Wer das umsetzt, sollte nach der Aussage suchen, nicht nach dem Wortlaut. Ebenfalls zu prüfen: `.github/workflows/change-app-version.yml` nennt für `freesailarr` weiterhin „nine images"; seit MediathekArr sind es zehn. Gleiche Fehlerklasse, andere Datei — dort ohne Versions- und Veröffentlichungskosten.
jlab-bot commented 2026-09-26 23:37:20 +02:00
Author
Member
Copy link
Copy source

Entschieden (Manager-Sitzung): Weg 1 — alle Charts in einem Durchgang. Das Issue bleibt offen, bis der Satz überall korrigiert ist; die Mitnahme-Lösung ist damit vom Tisch.

Begründung: Die Mitnahme-Variante hätte den Zustand über Monate gestreckt, in denen sich die Charts untereinander widersprechen — und die Wahrscheinlichkeit, dass der Rest liegen bleibt, ist bei einem Satz, der niemandem wehtut, hoch. Rund zwanzig Patch-Bumps sind der Preis dafür, dass das Thema danach erledigt ist.

Vorgaben für die Umsetzung

  • Nach der Aussage suchen, nicht nach dem Wortlaut. In searxng stand dieselbe Behauptung zusätzlich in values.yaml und verwies dort auf die falsche Richtliniennummer. Der Satz kann in Kopfkommentaren, in Helfer-Beschreibungen und in Werte-Kommentaren stehen.
  • Was an die Stelle tritt, ist die Begründung, die tatsächlich trägt: Geteilt würde der Helfer über ein Library-Chart — ein zweites Artefakt zum Veröffentlichen, Versionieren und Ziehen, für etwa eine Änderung pro Jahr. Abhängigkeiten sind seit #214 zulässig, aber teuer, und stehen als Richtlinie 14 in der README. Die Formulierung in searxng/templates/_helpers.tpl ist die Vorlage, sie wurde in PR #38 bereits so geschrieben.
  • Je Chart ein Patch-Bump, appVersion unverändert, Suffix unverändert. template-chart ist ausgenommen (wird nie veröffentlicht, Versionsprüfung greift dort nicht), muss aber korrigiert werden — von dort erbt jedes neue Chart den Satz.
  • Mit erledigen, ohne Versionskosten: .github/workflows/change-app-version.yml nennt für freesailarr weiterhin „nine images"; seit MediathekArr sind es zehn.
  • Keine Wiki-Änderung nötig. Der Eingriff ändert weder Werte noch Verhalten; nach der Tabelle in CLAUDE.md löst er keine Pflicht aus.

Ein Risiko, das aus #38 gelernt ist

Zwanzig gleichzeitig angefasste Chart.yaml treffen auf einen Renovate-Bot, der seit #34 unbegrenzt und für alle Aktualisierungstypen automatisch merged. Jede Renovate-Runde, die währenddessen landet, erzeugt einen Konflikt in genau diesen Dateien. Deshalb: unmittelbar vor dem Öffnen des PR rebasen, und der PR sollte nicht tagelang offen liegen.

Entschieden (Manager-Sitzung): **Weg 1 — alle Charts in einem Durchgang.** Das Issue bleibt offen, bis der Satz überall korrigiert ist; die Mitnahme-Lösung ist damit vom Tisch. Begründung: Die Mitnahme-Variante hätte den Zustand über Monate gestreckt, in denen sich die Charts untereinander widersprechen — und die Wahrscheinlichkeit, dass der Rest liegen bleibt, ist bei einem Satz, der niemandem wehtut, hoch. Rund zwanzig Patch-Bumps sind der Preis dafür, dass das Thema danach erledigt ist. ## Vorgaben für die Umsetzung - **Nach der Aussage suchen, nicht nach dem Wortlaut.** In searxng stand dieselbe Behauptung zusätzlich in `values.yaml` und verwies dort auf die falsche Richtliniennummer. Der Satz kann in Kopfkommentaren, in Helfer-Beschreibungen und in Werte-Kommentaren stehen. - **Was an die Stelle tritt, ist die Begründung, die tatsächlich trägt:** Geteilt würde der Helfer über ein Library-Chart — ein zweites Artefakt zum Veröffentlichen, Versionieren und Ziehen, für etwa eine Änderung pro Jahr. Abhängigkeiten sind seit #214 zulässig, aber teuer, und stehen als Richtlinie 14 in der README. Die Formulierung in `searxng/templates/_helpers.tpl` ist die Vorlage, sie wurde in PR #38 bereits so geschrieben. - **Je Chart ein Patch-Bump**, `appVersion` unverändert, Suffix unverändert. `template-chart` ist ausgenommen (wird nie veröffentlicht, Versionsprüfung greift dort nicht), muss aber korrigiert werden — von dort erbt jedes neue Chart den Satz. - **Mit erledigen, ohne Versionskosten:** `.github/workflows/change-app-version.yml` nennt für `freesailarr` weiterhin „nine images"; seit MediathekArr sind es zehn. - **Keine Wiki-Änderung nötig.** Der Eingriff ändert weder Werte noch Verhalten; nach der Tabelle in CLAUDE.md löst er keine Pflicht aus. ## Ein Risiko, das aus #38 gelernt ist Zwanzig gleichzeitig angefasste `Chart.yaml` treffen auf einen Renovate-Bot, der seit #34 unbegrenzt und für alle Aktualisierungstypen automatisch merged. Jede Renovate-Runde, die währenddessen landet, erzeugt einen Konflikt in genau diesen Dateien. Deshalb: unmittelbar vor dem Öffnen des PR rebasen, und der PR sollte nicht tagelang offen liegen.
jlab-bot reopened this issue 2026-09-27 12:48:07 +02:00
jlab-bot commented 2026-09-27 12:48:21 +02:00
Author
Member
Copy link
Copy source

Wieder geöffnet. PR #48 ist gemergt und hat 40 der 41 Vorkommen in 21 von 22 Charts korrigiert, aber der Satz steht noch in rss-bridge/templates/_helpers.tpl:18.

rss-bridge musste aus #48 heraus, weil sein Install-Test auf dem Gitea-Runner scheitert (uid 33 kann /app/index.php nicht lesen, Startup-Probe 403) — aus einem Grund, der älter ist als dieser Branch, siehe #51. Das Chart im Diff zu lassen hätte es in der Install-Test-Matrix gehalten und den Check der übrigen 21 Charts rot gehalten. Die Kommentar-Korrektur für rss-bridge ist in #51 als Aufgabe vermerkt, weil das Chart dort ohnehin geöffnet wird.

Die Entscheidung „alle Charts in einem Durchgang" bleibt damit gewahrt; es bleibt ein bekannter, verfolgter Rest von genau einem Chart. Dieses Issue schließt, wenn #51 gelandet ist.

Zur Berichtigung meiner Diagnose in #48: Der Verdacht, das Datums-Tag rssbridge/rss-bridge:2025-08-05 sei neu gepusht worden, ist widerlegt — der gezogene Digest trägt das Erstellungsdatum seines eigenen Tags. Die Ursache liegt beim Runner, nicht beim Image; #51 hält das ausführlich fest.

Wieder geöffnet. PR #48 ist gemergt und hat **40 der 41 Vorkommen in 21 von 22 Charts** korrigiert, aber der Satz steht noch in `rss-bridge/templates/_helpers.tpl:18`. `rss-bridge` musste aus #48 heraus, weil sein Install-Test auf dem Gitea-Runner scheitert (uid 33 kann `/app/index.php` nicht lesen, Startup-Probe 403) — aus einem Grund, der älter ist als dieser Branch, siehe #51. Das Chart im Diff zu lassen hätte es in der Install-Test-Matrix gehalten und den Check der übrigen 21 Charts rot gehalten. Die Kommentar-Korrektur für `rss-bridge` ist in #51 als Aufgabe vermerkt, weil das Chart dort ohnehin geöffnet wird. Die Entscheidung „alle Charts in einem Durchgang" bleibt damit gewahrt; es bleibt ein bekannter, verfolgter Rest von genau einem Chart. Dieses Issue schließt, wenn #51 gelandet ist. Zur Berichtigung meiner Diagnose in #48: Der Verdacht, das Datums-Tag `rssbridge/rss-bridge:2025-08-05` sei neu gepusht worden, ist widerlegt — der gezogene Digest trägt das Erstellungsdatum seines eigenen Tags. Die Ursache liegt beim Runner, nicht beim Image; #51 hält das ausführlich fest.
Sign in to join this conversation.
No Branch/Tag Specified
Labels
Clear labels
inhouse-chart
Inhouse-Chart aus der JLab-Git-Paketregistry
 renovate
Von Renovate angelegt
No labels
Milestone
No items
No Milestone
Assignees
Clear assignees
jklein (Justin Klein) jlab-bot (jlab-git-bot) jlab-renovate-bot (jlab-renovate-bot)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: jlab-cluster/helm-charts#40