Correct the dead no-dependencies rationale in every chart helper #48

Merged

jklein merged 1 commits from docs/helper-dependency-rationale into main 2026-09-27 12:45:14 +02:00

Conversation 3 Commits 1 Files Changed 43

+184 -126

jlab-bot commented 2026-09-26 23:43:29 +02:00

Member

Copy link

Copy source

Fixes #40

The doc comment on the resources and defaultedDict helpers justified the copy-per-chart with a rule that no longer exists:

charts in this repo deliberately have no dependencies

That fell with #214 — a dependency is admissible now, only expensive, and the rule sits in the README as guideline 14, not 13. The design decision it defends is still right; its stated reason is not. What replaces it is the reason that actually carries: sharing the helper would mean a library chart, a second artefact to publish, version and pull for something that changes about once a year. searxng was written that way in PR #38 and is the template here.

Inventory

41 occurrences in 22 charts — one in the resources header comment, one in the defaultedDict header comment, except in freesailarr, paperless-ngx and rss-bridge, which carry only the first.

Of those, 40 occurrences in 21 charts are corrected here. rss-bridge is left out on purpose — see below.

Not touched, and why:

• searxng — corrected in PR #38, verified unchanged.
• sure — its helper comment never made the claim ("rather than shared through a library chart").
• ytdlp-web-player — the one chart with a dependency; its comment already names the old rule as old.

Searched for the assertion, not the wording: _helpers.tpl, values.yaml, values.schema.json descriptions, NOTES.txt and Chart.yaml across every chart. No second site outside the helpers (the searxng case, where the claim also sat in values.yaml, has no counterpart elsewhere). The three surviving hits for the phrase — CLAUDE.md, README.md, ytdlp-web-player/Chart.yaml — all quote the rule explicitly as the former one and are correct as they stand.

Why rss-bridge is not in this PR

Its install-test fails on the Gitea runner, and it fails for a reason that predates this branch. php-fpm runs as uid 33 and cannot read /app/index.php, so the startup probe gets 403 for its whole 150s budget and the pod never becomes Ready. Tracked in #51.

The cause is not an image re-push — that was my first reading and it was measured wrong. The registry says the pulled digest carries the creation date of its own tag:

rssbridge/rss-bridge:2025-08-05 -> sha256:569f01f3…  created 2025-08-05T17:53:25Z
rssbridge/rss-bridge:latest     -> sha256:60689611…  created 2026-08-28T16:50:42Z

A later rebuild of the date tag would carry a later timestamp. It does not, so the tag was never re-pushed. What changed is the runner: rss-bridge was last touched on 2026-08-29, before the move, so this PR produced its first run on the Gitea runner — and a dind with userns-remap shifts exactly the file ownership that uid 33 depends on here. README names user namespaces as unmeasured. Details in #51.

The chart is therefore restored to main exactly — comment correction and the 1.0.2 → 1.0.3 step reverted — so it leaves the install-test matrix entirely. Its copy of the sentence is carried by #51, which has to open the chart anyway. #40 stays open until that lands; the "all charts in one pass" decision holds, with one known and tracked remainder.

What the failed run did prove

This PR accidentally became the first all-charts install-test since the move to Gitea, and the result is worth having: 19 of 20 charts in the matrix installed and became Ready on the Gitea runner, under the conditions that have applied since the move. Exactly one failed. Recorded as a finding in #52, which is about the absence of a periodic all-charts run.

Versions

Every touched chart is published, so every touched chart takes a patch bump; appVersion and the +up suffix are untouched. template-chart is never published and the version check skips it, so it takes no bump — but it is corrected, because every new chart inherits the comment from it.

Chart	Version
apache-tika	10.0.1 → 10.0.2
bentopdf	1.0.2 → 1.0.3
calibre-web-automated	7.0.0 → 7.0.1
cyberchef	9.0.1 → 9.0.2
freesailarr	3.1.0 → 3.1.1
gotenberg	8.0.2 → 8.0.3
homeassistant	6.1.0 → 6.1.1
matrix-synapse	7.1.0 → 7.1.1
minecraft-router	4.1.2 → 4.1.3
minecraft-server	6.0.0 → 6.0.1
outline	7.1.2 → 7.1.3
paperless-ngx	12.1.2 → 12.1.3
patchmon	7.0.1 → 7.0.2
rallly	8.1.5 → 8.1.6
samba	7.1.0 → 7.1.1
satisfactory	7.0.1 → 7.0.2
teamspeak-server	5.1.2 → 5.1.3
urlaubsverwaltung	10.0.0 → 10.0.1
voucher-vault	6.1.1 → 6.1.2
zipline	7.1.0 → 7.1.1
template-chart	— (never published)

20 bumps, 21 chart directories touched, 43 files in all.

Taken along, at no version cost

• .github/workflows/change-app-version.yml counted nine images for freesailarr; since MediathekArr it is ten.
• .github/workflows/validate-charts.yml explained the all-charts quantity render test with the same dead rule ("because charts here have no dependencies"); it now names the library-chart reason.

Verification

Re-run after the rebase onto 9df2b68 and after rss-bridge was taken out:

• helm lint --strict clean for all 21 touched charts.
• ci/run-quantity-render-test.sh over every chart: 23 exercised, 2 not exercised (gotenberg, rss-bridge — unchanged from before), 0 failed.
• Every touched chart renders byte-identical to the branch base. Rendered against ci/<chart>/test-values.yaml for the 19 charts that have fixtures, and against real required values for the two that do not (satisfactory, template-chart). This change is comments only, so anything but byte-identical would have been a mistake.
• rss-bridge/ confirmed absent from the diff against main.
• No Docker daemon in this environment; the PR install-test is the runtime proof.

No wiki change

Neither values nor behaviour move, so per the table in CLAUDE.md this triggers no wiki obligation.

The Renovate collision, for the record

It happened: while this PR was open, Renovate automerged paperless-ngx to appVersion 3.2.1 and took the chart patch number 12.1.2 — the one this branch had taken for the comment fix. Resolved the way that rule prescribes: the bump is re-derived from the new value, not defended. paperless-ngx is now 12.1.3+up3.2.1 with Renovate's appVersion: 3.2.1 untouched, and the whole verification set above was re-run against the new base afterwards.

Fixes #40 The doc comment on the `resources` and `defaultedDict` helpers justified the copy-per-chart with a rule that no longer exists: > charts in this repo deliberately have no dependencies That fell with #214 — a dependency is admissible now, only expensive, and the rule sits in the README as guideline **14**, not 13. The design decision it defends is still right; its stated reason is not. What replaces it is the reason that actually carries: sharing the helper would mean a **library chart**, a second artefact to publish, version and pull for something that changes about once a year. `searxng` was written that way in PR #38 and is the template here. ## Inventory **41 occurrences in 22 charts** — one in the `resources` header comment, one in the `defaultedDict` header comment, except in `freesailarr`, `paperless-ngx` and `rss-bridge`, which carry only the first. Of those, **40 occurrences in 21 charts** are corrected here. `rss-bridge` is left out on purpose — see below. Not touched, and why: - `searxng` — corrected in PR #38, verified unchanged. - `sure` — its helper comment never made the claim ("rather than shared through a library chart"). - `ytdlp-web-player` — the one chart with a dependency; its comment already names the old rule as old. Searched for the assertion, not the wording: `_helpers.tpl`, `values.yaml`, `values.schema.json` descriptions, `NOTES.txt` and `Chart.yaml` across every chart. No second site outside the helpers (the searxng case, where the claim also sat in `values.yaml`, has no counterpart elsewhere). The three surviving hits for the phrase — `CLAUDE.md`, `README.md`, `ytdlp-web-player/Chart.yaml` — all quote the rule explicitly as the former one and are correct as they stand. ## Why `rss-bridge` is not in this PR Its install-test fails on the Gitea runner, and it fails for a reason that predates this branch. php-fpm runs as uid 33 and cannot read `/app/index.php`, so the startup probe gets **403** for its whole 150s budget and the pod never becomes Ready. Tracked in **#51**. The cause is **not** an image re-push — that was my first reading and it was measured wrong. The registry says the pulled digest carries the creation date of its own tag: ``` rssbridge/rss-bridge:2025-08-05 -> sha256:569f01f3… created 2025-08-05T17:53:25Z rssbridge/rss-bridge:latest -> sha256:60689611… created 2026-08-28T16:50:42Z ``` A later rebuild of the date tag would carry a later timestamp. It does not, so the tag was never re-pushed. What changed is the **runner**: `rss-bridge` was last touched on 2026-08-29, before the move, so this PR produced its first run on the Gitea runner — and a dind with userns-remap shifts exactly the file ownership that uid 33 depends on here. README names user namespaces as unmeasured. Details in #51. The chart is therefore restored to `main` exactly — comment correction *and* the `1.0.2 → 1.0.3` step reverted — so it leaves the install-test matrix entirely. Its copy of the sentence is carried by #51, which has to open the chart anyway. **#40 stays open until that lands**; the "all charts in one pass" decision holds, with one known and tracked remainder. ## What the failed run did prove This PR accidentally became the **first all-charts install-test since the move to Gitea**, and the result is worth having: **19 of 20 charts in the matrix installed and became Ready** on the Gitea runner, under the conditions that have applied since the move. Exactly one failed. Recorded as a finding in **#52**, which is about the absence of a periodic all-charts run. ## Versions Every touched chart is published, so every touched chart takes a **patch bump**; `appVersion` and the `+up` suffix are untouched. `template-chart` is never published and the version check skips it, so it takes no bump — but it is corrected, because every new chart inherits the comment from it. | Chart | Version | | --- | --- | | apache-tika | 10.0.1 → 10.0.2 | | bentopdf | 1.0.2 → 1.0.3 | | calibre-web-automated | 7.0.0 → 7.0.1 | | cyberchef | 9.0.1 → 9.0.2 | | freesailarr | 3.1.0 → 3.1.1 | | gotenberg | 8.0.2 → 8.0.3 | | homeassistant | 6.1.0 → 6.1.1 | | matrix-synapse | 7.1.0 → 7.1.1 | | minecraft-router | 4.1.2 → 4.1.3 | | minecraft-server | 6.0.0 → 6.0.1 | | outline | 7.1.2 → 7.1.3 | | paperless-ngx | 12.1.2 → 12.1.3 | | patchmon | 7.0.1 → 7.0.2 | | rallly | 8.1.5 → 8.1.6 | | samba | 7.1.0 → 7.1.1 | | satisfactory | 7.0.1 → 7.0.2 | | teamspeak-server | 5.1.2 → 5.1.3 | | urlaubsverwaltung | 10.0.0 → 10.0.1 | | voucher-vault | 6.1.1 → 6.1.2 | | zipline | 7.1.0 → 7.1.1 | | template-chart | — (never published) | **20 bumps**, 21 chart directories touched, 43 files in all. ## Taken along, at no version cost - `.github/workflows/change-app-version.yml` counted **nine** images for `freesailarr`; since MediathekArr it is **ten**. - `.github/workflows/validate-charts.yml` explained the all-charts quantity render test with the same dead rule ("because charts here have no dependencies"); it now names the library-chart reason. ## Verification Re-run after the rebase onto `9df2b68` and after `rss-bridge` was taken out: - `helm lint --strict` clean for all 21 touched charts. - `ci/run-quantity-render-test.sh` over every chart: 23 exercised, 2 not exercised (`gotenberg`, `rss-bridge` — unchanged from before), **0 failed**. - **Every touched chart renders byte-identical to the branch base.** Rendered against `ci/<chart>/test-values.yaml` for the 19 charts that have fixtures, and against real required values for the two that do not (`satisfactory`, `template-chart`). This change is comments only, so anything but byte-identical would have been a mistake. - `rss-bridge/` confirmed absent from the diff against `main`. - No Docker daemon in this environment; the PR install-test is the runtime proof. ## No wiki change Neither values nor behaviour move, so per the table in `CLAUDE.md` this triggers no wiki obligation. ## The Renovate collision, for the record It happened: while this PR was open, Renovate automerged `paperless-ngx` to appVersion 3.2.1 and took the chart patch number `12.1.2` — the one this branch had taken for the comment fix. Resolved the way that rule prescribes: the bump is **re-derived from the new value**, not defended. `paperless-ngx` is now `12.1.3+up3.2.1` with Renovate's `appVersion: 3.2.1` untouched, and the whole verification set above was re-run against the new base afterwards.

jklein approved these changes 2026-09-27 00:01:19 +02:00

jlab-bot commented 2026-09-27 00:11:12 +02:00

Author

Member

Copy link

Copy source

Install-test: 19 of 20 green, rss-bridge red — and not from this change

Validate Helm Charts / Install-test failed after 16m52s. One chart of the matrix failed; the other 19 installed and became Ready (satisfactory and template-chart are in ci/excluded-charts.txt, so 19 + 1 + 2 = 22).

Failing chart: rss-bridge. Startup probe answers 403 for the whole 150s budget, the container is restarted once, and kubectl rollout status times out. The container log names the cause and it is not the probe:

ERROR: Unable to open primary script: /app/index.php (Permission denied)
GET /?action=health HTTP/1.1" 403

Also in the same log, and new:

ERROR: ld.so: object /usr/local/lib/curl-impersonate/libcurl-impersonate.so
from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.

php-fpm runs as uid 33 and cannot read /app/index.php. That contradicts what rss-bridge/values.yaml states as measured fact and builds its whole security context on:

uid/gid 33 is www-data, and it is not interchangeable: /app and every file in it is owned by www-data in the image

So the image at docker.io/rssbridge/rss-bridge:2025-08-05 no longer matches that measurement. The runner pulled sha256:569f01f3faecd0d34d702e01b34eb0a769f7bedb84caf6dff29821d18b46f971, which is what that tag resolves to on Docker Hub right now — a date tag that was re-pushed, the LD_PRELOAD line being the second sign of it.

Why this is not caused by this PR

This PR changes comments. Verified before pushing: every touched chart, rss-bridge included, renders byte-identical to the branch base against its ci/<chart>/test-values.yaml. The pod spec the runner installed is the one main produces today. rss-bridge was last changed on 2026-08-29 (e666cfe), and the install-test only runs for changed charts — so nothing has installed this chart since, and the re-push has been invisible until this PR touched the chart and enrolled it again.

This is exactly the failure class README already names under "Green does not mean checked": a chart that nothing installs cannot go red, however broken it is. rss-bridge as published is currently unable to start.

What I have not done

Fixing it means a runtime change to rss-bridge (its uid, or /app ownership, or the hardening around it) plus a re-measurement against the new image, and it needs its own issue, its own version bump and its own wiki round. It does not belong in a comment correction, so the chart content is untouched here and the red check is not papered over.

Decision needed on how to proceed with this PR — no merge and no auto-merge from me.

## Install-test: 19 of 20 green, `rss-bridge` red — and not from this change `Validate Helm Charts / Install-test` failed after 16m52s. One chart of the matrix failed; the other 19 installed and became Ready (`satisfactory` and `template-chart` are in `ci/excluded-charts.txt`, so 19 + 1 + 2 = 22). Failing chart: **rss-bridge**. Startup probe answers **403** for the whole 150s budget, the container is restarted once, and `kubectl rollout status` times out. The container log names the cause and it is not the probe: ``` ERROR: Unable to open primary script: /app/index.php (Permission denied) GET /?action=health HTTP/1.1" 403 ``` Also in the same log, and new: ``` ERROR: ld.so: object /usr/local/lib/curl-impersonate/libcurl-impersonate.so from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored. ``` php-fpm runs as uid 33 and cannot read `/app/index.php`. That contradicts what `rss-bridge/values.yaml` states as measured fact and builds its whole security context on: > uid/gid 33 is www-data, and it is not interchangeable: /app and every file in it is owned by www-data in the image So the image at `docker.io/rssbridge/rss-bridge:2025-08-05` no longer matches that measurement. The runner pulled `sha256:569f01f3faecd0d34d702e01b34eb0a769f7bedb84caf6dff29821d18b46f971`, which is what that tag resolves to on Docker Hub right now — a **date tag that was re-pushed**, the LD_PRELOAD line being the second sign of it. ### Why this is not caused by this PR This PR changes comments. Verified before pushing: every touched chart, `rss-bridge` included, renders **byte-identical** to the branch base against its `ci/<chart>/test-values.yaml`. The pod spec the runner installed is the one `main` produces today. `rss-bridge` was last changed on 2026-08-29 (`e666cfe`), and the install-test only runs for changed charts — so nothing has installed this chart since, and the re-push has been invisible until this PR touched the chart and enrolled it again. This is exactly the failure class README already names under "Green does not mean checked": a chart that nothing installs cannot go red, however broken it is. `rss-bridge` as published is currently unable to start. ### What I have not done Fixing it means a runtime change to `rss-bridge` (its uid, or `/app` ownership, or the hardening around it) plus a re-measurement against the new image, and it needs its own issue, its own version bump and its own wiki round. It does not belong in a comment correction, so the chart content is untouched here and the red check is not papered over. Decision needed on how to proceed with this PR — no merge and no auto-merge from me.

jlab-bot commented 2026-09-27 00:14:11 +02:00

Author

Member

Copy link

Copy source

Korrektur zur Diagnose im Kommentar darüber, gemessen von der Manager-Sitzung: Das Image wurde nicht neu gebaut. Die Ursache liegt mit hoher Wahrscheinlichkeit im Runner, nicht bei Docker Hub.

Was gemessen ist

Anonym gegen die Docker-Registry abgefragt:

docker.io/rssbridge/rss-bridge:2025-08-05
  -> sha256:569f01f3faecd0d34d702e01b34eb0a769f7bedb84caf6dff29821d18b46f971
     created 2025-08-05T17:53:25Z

docker.io/rssbridge/rss-bridge:latest
  -> sha256:606896116558c57e3d381dec6874457f7a69216103d77c78b5bd38b92b251902
     created 2026-08-28T16:50:42Z

Der Digest, den der Runner gezogen hat, trägt als Erstellungszeitpunkt genau das Datum seines Tags. Ein nachträglicher Neubau hätte ein späteres Datum. Die Vermutung „Datums-Tag wurde neu gepusht" ist damit widerlegt, und der zweite Beleg dafür — die neue LD_PRELOAD-Zeile — braucht eine andere Erklärung.

Was daraus folgt

Drei Dinge sind gleichzeitig wahr:

1. Das Chart in diesem PR rendert byte-identisch zu main (vom Umsetzungs-Agenten belegt).
2. Das Image ist unveränderlich und trägt dasselbe Datum wie sein Tag.
3. rss-bridge wurde zuletzt am 2026-08-29 geändert (e666cfe) — also vor dem Umzug auf Gitea.

Gleiches Chart plus gleiches Image plus anderes Ergebnis heißt: Der Unterschied liegt in der Umgebung. Der letzte grüne Install-Test dieses Charts lief auf einem GitHub-Runner; weil der Install-Test nur geänderte Charts erfasst, ist dieser Lauf hier der erste auf dem Gitea-Runner überhaupt.

Damit ist das genau der Fall, den die README unter „What a GitHub runner had been providing quietly" beschreibt — und sie nennt dort ausdrücklich als unvermessen: /dev/fuse und User-Namespaces. Ein dind-Runner mit userns-remap verschiebt die Eigentümerschaft der Image-Dateien aus Sicht des Containers, und genau so sieht das Symptom aus: uid 33 darf /app/index.php nicht lesen, und auch die .so für LD_PRELOAD nicht.

Das ist eine Hypothese, keine Messung. Zu prüfen ist sie am Runner, nicht am Chart: docker info auf userns und die dind-Konfiguration, dann dieselbe Image-Version in einem lokalen k3d ohne Remapping gegenprüfen.

Was das für die Bewertung ändert

• „rss-bridge as published cannot currently start" ist nicht belegt. Möglicherweise scheitert nur der Install-Test in dieser Umgebung, während die laufende Installation unberührt ist. Umgekehrt ist auch nicht belegt, dass sie gesund ist — beides steht offen.
• Die Aussage im Chart-Kommentar („/app und jede Datei darin gehört www-data im Image") ist durch diesen Lauf nicht widerlegt, sondern nur im Kontext dieses Runners nicht reproduzierbar.
• Der Befund ist größer als dieses Chart. Nach demselben Argument gilt für jedes Chart, das seit dem Umzug nicht angefasst wurde: Sein letzter grüner Install-Test stammt aus einer anderen Umgebung. Die grüne Historie beweist für diese Charts nichts über den heutigen Runner.

An diesem PR ist nichts zu ändern; die Entscheidung über den Umgang mit dem roten Check trifft der Betreuer.

Korrektur zur Diagnose im Kommentar darüber, gemessen von der Manager-Sitzung: **Das Image wurde nicht neu gebaut. Die Ursache liegt mit hoher Wahrscheinlichkeit im Runner, nicht bei Docker Hub.** ## Was gemessen ist Anonym gegen die Docker-Registry abgefragt: ``` docker.io/rssbridge/rss-bridge:2025-08-05 -> sha256:569f01f3faecd0d34d702e01b34eb0a769f7bedb84caf6dff29821d18b46f971 created 2025-08-05T17:53:25Z docker.io/rssbridge/rss-bridge:latest -> sha256:606896116558c57e3d381dec6874457f7a69216103d77c78b5bd38b92b251902 created 2026-08-28T16:50:42Z ``` Der Digest, den der Runner gezogen hat, trägt als Erstellungszeitpunkt **genau das Datum seines Tags**. Ein nachträglicher Neubau hätte ein späteres Datum. Die Vermutung „Datums-Tag wurde neu gepusht" ist damit widerlegt, und der zweite Beleg dafür — die neue `LD_PRELOAD`-Zeile — braucht eine andere Erklärung. ## Was daraus folgt Drei Dinge sind gleichzeitig wahr: 1. Das Chart in diesem PR rendert **byte-identisch** zu `main` (vom Umsetzungs-Agenten belegt). 2. Das Image ist unveränderlich und trägt dasselbe Datum wie sein Tag. 3. `rss-bridge` wurde zuletzt am **2026-08-29** geändert (`e666cfe`) — also **vor** dem Umzug auf Gitea. Gleiches Chart plus gleiches Image plus anderes Ergebnis heißt: Der Unterschied liegt in der Umgebung. Der letzte grüne Install-Test dieses Charts lief auf einem **GitHub-Runner**; weil der Install-Test nur geänderte Charts erfasst, ist dieser Lauf hier **der erste auf dem Gitea-Runner überhaupt**. Damit ist das genau der Fall, den die README unter „What a GitHub runner had been providing quietly" beschreibt — und sie nennt dort ausdrücklich als **unvermessen**: `/dev/fuse` und **User-Namespaces**. Ein dind-Runner mit userns-remap verschiebt die Eigentümerschaft der Image-Dateien aus Sicht des Containers, und genau so sieht das Symptom aus: uid 33 darf `/app/index.php` nicht lesen, und auch die `.so` für LD_PRELOAD nicht. Das ist eine Hypothese, keine Messung. Zu prüfen ist sie am Runner, nicht am Chart: `docker info` auf `userns` und die dind-Konfiguration, dann dieselbe Image-Version in einem lokalen k3d ohne Remapping gegenprüfen. ## Was das für die Bewertung ändert - **„rss-bridge as published cannot currently start" ist nicht belegt.** Möglicherweise scheitert nur der Install-Test in dieser Umgebung, während die laufende Installation unberührt ist. Umgekehrt ist auch nicht belegt, dass sie gesund ist — beides steht offen. - **Die Aussage im Chart-Kommentar** („/app und jede Datei darin gehört www-data im Image") ist durch diesen Lauf nicht widerlegt, sondern nur im Kontext dieses Runners nicht reproduzierbar. - **Der Befund ist größer als dieses Chart.** Nach demselben Argument gilt für jedes Chart, das seit dem Umzug nicht angefasst wurde: Sein letzter grüner Install-Test stammt aus einer anderen Umgebung. Die grüne Historie beweist für diese Charts nichts über den heutigen Runner. An diesem PR ist nichts zu ändern; die Entscheidung über den Umgang mit dem roten Check trifft der Betreuer.

jlab-bot referenced this pull request 2026-09-27 12:04:13 +02:00

rss-bridge: Install-Test scheitert auf dem Gitea-Runner (uid 33 kann /app/index.php nicht lesen) #51

jlab-bot referenced this pull request 2026-09-27 12:05:20 +02:00

Install-Test: kein Rundumtest ueber alle Charts - Umgebungsdrift bleibt unentdeckt #52

jklein force-pushed docs/helper-dependency-rationale from cbddba6972 to 2ea8d25944 2026-09-27 12:07:57 +02:00 Compare

jklein added 1 commit 2026-09-27 12:28:25 +02:00

Replace the obsolete no-dependencies rationale in every chart helper ... e0b552d93e

The doc comments on the resources and defaultedDict helpers justified the
copy-per-chart with "charts in this repo deliberately have no dependencies".
That rule fell with #214: a dependency is admissible now, just expensive, and
it sits in the README as guideline 14, not 13. The justification still holds,
but its reason is a different one - sharing the helper would mean a library
chart, a second artefact to publish, version and pull for something that
changes about once a year. searxng got that wording in PR #38; this carries it
to 21 further charts, 40 occurrences in all.

rss-bridge is deliberately left out. Its install-test fails on the Gitea
runner for a reason that predates this branch, and touching the chart would
keep it in the install-test matrix and the check red. Its copy of the sentence
is carried by #51, which has to open the chart anyway.

Comments only: every touched chart renders byte-identical against its
ci/<chart>/test-values.yaml. Each published chart takes a patch bump,
appVersion and +up suffix untouched; template-chart is never published and
takes none, but is corrected because every new chart inherits from it.

Two repo files carried the same claim at no version cost:
validate-charts.yml explained the all-charts quantity render test with it, and
change-app-version.yml still counted nine images for freesailarr - MediathekArr
made it ten.

jklein force-pushed docs/helper-dependency-rationale from 2ea8d25944 to e0b552d93e 2026-09-27 12:28:25 +02:00 Compare

jklein scheduled this pull request to auto merge when all checks succeed 2026-09-27 12:36:53 +02:00

jklein merged commit e0b552d93e into main 2026-09-27 12:45:14 +02:00

jklein deleted branch docs/helper-dependency-rationale 2026-09-27 12:45:14 +02:00

jlab-bot referenced this pull request 2026-09-27 12:48:21 +02:00

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

jklein referenced this issue from a commit 2026-09-27 16:31:30 +02:00

Make the all-charts install-test repeatable, as one shared job

jlab-bot referenced this pull request 2026-09-27 16:33:27 +02:00

Install-test over all charts, on demand, through one shared job #54

jlab-bot referenced this pull request 2026-09-27 22:46:40 +02:00

CLAUDE.md: PRs, die ihr Issue nicht abschliessen, brauchen "Part of #n" statt "Fixes #n" #55

jlab-bot referenced this pull request 2026-09-28 00:03:25 +02:00

docs: a PR that does not finish its issue writes "Part of #n", not "Fixes #n" #56

jlab-bot referenced this pull request 2026-10-13 11:59:24 +02:00

feat(rss-bridge): Gateway-API as an alternative to the Ingress (last chart of the sweep) #124

Sign in to join this conversation.

Reviewers

No Reviewers

jklein

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

2 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: jlab-cluster/helm-charts#48