17 Commits

Include renames

Author	SHA1	Message	Date
jlab-renovate-bot	352af685e2	Update docker.io/linuxserver/prowlarr Docker tag to v2.6.5	2026-10-11 12:06:07 +00:00
jklein	e0b552d93e	Replace the obsolete no-dependencies rationale in every chart helper ... 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.	2026-09-27 10:27:57 +00:00
jklein	78d7020dab	freesailarr: MediathekArr as the tenth container, off by default (3.1.0+up1.0.0) ... MediathekArr fakes a Usenet indexer towards Prowlarr and a SABnzbd downloader towards Sonarr/Radarr and fetches from the ARD and ZDF media libraries. Both consumers already share gluetun's network namespace, so they reach it over 127.0.0.1 - no service, no DNS, no ingress detour. Purely additive: the flag defaults to false and a default render is byte-identical to 3.0.5 (verified against the previous chart for both the default values and the CI values). The four things that fail silently without them: - A START GATE on gluetun. MediathekArr fetches its ruleset once at start and never retries; started before the tunnel it answers every Newznab search with 0 results while the container is up, Ready and quiet. Kubernetes cannot order two regular containers and an initContainer would deadlock, so the wait sits in front of the image entrypoint: poll gluetun's health server on 127.0.0.1:9999 and exec the entrypoint afterwards; on timeout the container exits rather than starting blind, because a crash loop is visible and an empty indexer is not. The startup probe budget (300s) deliberately outlasts the gate (180s). - incomplete/ AND complete/ ON THE SHARED DOWNLOADS CLAIM, not in an emptyDir. An emptyDir counts against the container's ephemeral-storage limit, and one large download would have the kubelet evict the whole pod with all ten containers - the trap ytdlp-web-player documents. - THE COMPLETE PATH SONARR SEES. The claim is mounted at /downloads exactly as sonarr/radarr mount it, and the chart sets DOWNLOAD_COMPLETE_PATH itself, so the SABnzbd complete_dir it reports is the same absolute path on both sides. - TWO PORTS: 5007 (SABnzbd role and UI, primary) and 5008 (Newznab role for Prowlarr), both declared to gluetun's firewall and both on one Service. The SABnzbd API is at /download/api - /api on 5007 answers with a misleading Newznab validation error. Further details: - Image pinned by digest (tag + digest): "latest" is a 2024 build, "beta" moves. Single-arch linux/amd64. The built-in helm-values manager cannot follow that pair, so renovate.json5 gets the chart's first customManagers block; verified by dry-run with two fixtures, since a matching and a broken rule look identical while the pin is current. - Hardened as measured: non-root, uid/gid from puid/pgid, readOnlyRootFilesystem: true, all capabilities dropped, no PUID/PGID. - Probes on measured 200 endpoints (there is no health endpoint): readiness and startup on /download/, liveness as an exec covering BOTH ports, because one container runs two processes and a wedged Newznab half is exactly what makes searches come back empty. - No ingress by default: the UI links its assets with root-absolute paths, so it can only be served at the root of a host; on the shared domain that root belongs to seerr. A sub-path fails the render instead of producing a broken UI. - values.yaml and NOTES.txt document the geo MARKER PROCEDURE (not a table of series), the escape route of a German exit and its price for the whole stack, the fail_message: null trap, and the HLS question as an open question. - CI: mediathekarr enabled in ci/freesailarr/test-values.yaml, install timeout raised to 1200s for the extra image and the gate. Fixes #245	2026-09-08 23:20:16 +02:00
jlab-renovate[bot]	df5e15b2b6	Update docker.io/linuxserver/bazarr Docker tag to v1.6.0	2026-08-30 01:20:22 +00:00
jlab-renovate[bot]	ed1e59b691	Update docker.io/linuxserver/prowlarr Docker tag to v2.5.2	2026-08-30 01:18:21 +00:00
jlab-renovate[bot]	131609fca1	Update docker.io/linuxserver/qbittorrent Docker tag to v5.2.3	2026-08-30 00:06:18 +00:00
jklein	ce73bc1111	freesailarr: no exponential notation in computed limits (3.0.2+up1.0.0) ... The null-safe fallback helpers from #99 route values through fromYaml, which parses every number as float64. Go's "%v" switches float64 to exponential notation from about 1e6 upwards, so a bare byte count like 1048576 reached the suffix check inside multiplyQuantity as "1.048576e+06" and the render aborted with `unsupported resource quantity suffix "e+06"`. Both printf "%v" sites in multiplyQuantity now go through a new formatNumber helper that forces plain decimal notation and trims the padded zeros. The second site is the quiet half of the bug: a fractional limitFactor together with a bare number produced no error at all, just an invalid quantity such as "1.4999985e+06" that only the API server rejects on apply. limitFactor is typed "number" in this chart's values.schema.json, so a fractional factor is an ordinary, schema-valid input. All ten resource paths of the stack are affected and were verified one by one (gluetun, qbittorrent and its configInit init container, prowlarr, flaresolverr, radarr, recyclarr, sonarr, seerr, bazarr). The VPN, firewall and container structure is untouched: rendering the chart with its default values is byte-identical to main. Teil von #157	2026-08-29 01:08:07 +02:00
jklein	69a280399c	ci: run the freesailarr install-test for real instead of skipping it ... freesailarr was excluded from the install-test because gluetun never becomes healthy without a real Wireguard key and no app container behind its kill switch can become Ready. The green "Install-test freesailarr pass" was a 25-second SKIP on the most complex chart in the repo - a signal that proved nothing. With a CI-only Mullvad key in 1Password the reason is gone: - ci/run-install-test.sh learns a general rule: ci/<chart>/fixtures.env.yaml is rendered with envsubst before it is applied, restricted to the variable names a chart declares in REQUIRED_ENV. A missing or empty declared variable fails the run loudly and names the variable - it never skips the chart. - The install-test job loads the key from 1Password Connect for freesailarr only, following the pattern publish-helm-chart.yml documents: values via steps.<id>.outputs.*, mapped into the step's own env, quoted, with ":?" guards that name the missing op:// field before a cluster is created. - Fixtures for freesailarr: three media claims, the gluetun secret template with variable names only, firewallOutboundSubnets so the kill switch does not block cluster DNS, and INSTALL_TIMEOUT=900 for nine containers. freesailarr/Chart.yaml goes 3.0.0+up1.0.0 -> 3.0.1+up1.0.0. That bump is deliberately empty of content: the install-test matrix follows changed chart directories, and without it this PR could not run the test it adds.	2026-08-26 14:30:42 +02:00
jklein	fc768efaf5	freesailarr: shared domain with sub-paths, qBittorrent save path (3.0.0+up1.0.0) ... Adds a second, optional ingress shape and fixes the download target of qBittorrent. The existing per-app-host shape stays the default and renders unchanged. Shared domain (#167) Setting ingress.host moves every app without a host of its own into one Ingress object with one path each (<app>.ingress.path, default /<app>), one TLS secret and therefore one DNS name and one certificate for the whole stack. A per-app host always wins and keeps its own object, so mixed operation needs no extra values. The apps differ in what they can do under a sub-path, and the chart follows that rather than pretending they are alike: - radarr, sonarr, prowlarr get <APP>__SERVER__URLBASE from the chart, but only when their own env block does not already carry the variable. - bazarr has no environment variable for its base path and stays one documented manual step (Settings -> General -> Base URL). - qbittorrent has no base path at all and renders a second object on the same host with a prefix-stripping rewrite. It repeats the same TLS secret name and deliberately omits the cert-manager annotation, so both objects state their own TLS while only one certificate is requested. - seerr has no base path either and cannot be rewritten, so it is pinned to "/" and a fail refuses any other path. A second fail refuses two apps claiming the same path. qBittorrent save path (#166) Without Session\DefaultSavePath qBittorrent writes to its built-in default /config/Downloads - the 1Gi config volume. It fills within minutes, every torrent goes to "errored" and qBittorrent can no longer write its own metadata to BT_backup, so a restart in that state costs the torrent list. The init container (renamed qbittorrent-config-interface -> qbittorrent-config-seed, since it no longer only sets the interface) now seeds qbittorrent.savePath, default /downloads. Unlike the interface binding it is inserted ONLY when the key is absent and never replaced: a path changed in the WebUI is a legitimate operator decision and must survive a restart. This is the reason for the major bump: an installation that never set the path writes somewhere else after the upgrade. Documentation NOTES.txt and the media block in values.yaml now spell out why a shared claim with three subPaths does not produce hardlinks: the kernel compares the vfsmount in do_linkat, not the superblock, so two bind mounts of one filesystem are EXDEV - while stat reports the same device number on both sides and suggests the opposite. The layout that would work (one claim, one mount, categories as sub-directories) is named as a possibility; the chart cannot express it today. README.md gains the shared domain as the second admissible ingress shape of the style guideline.	2026-08-25 20:55:43 +02:00
jklein	39e9613ee3	freesailarr: one volume entry per media claim (2.0.2+up1.0.0) ... media.downloads, media.movies and media.tv rendered three fixed volume entries, one per category. Two categories on the same existingClaim therefore produced two pod volumes with an identical claimName, and such a pod never starts: it stays in Init:0/1 without a single kubelet event (measured on RKE2/Longhorn, RWO and RWX alike). The volume list is now deduplicated by claim name. A new mediaVolumeName helper names the entry after the first ENABLED category in the fixed order downloads, movies, tv that carries the claim; the other categories mount that same entry and differ only in their subPath. The restriction to enabled categories matters because the three entries render under different conditions - a canonical owner whose entry is not rendered would be a dangling reference. With three distinct claims the chart renders byte-identically to 2.0.1, hence a patch bump. Also corrected in the values documentation, after measuring instead of assuming: the kubelet creates missing subPath directories itself, but they inherit the claim root's mode, and fsGroup cannot be relied on to fix that - Longhorn's fsGroupPolicy (ReadWriteOnceWithFSType) skips fsGroup on RWX claims entirely. What has to hold is that the claim root is writable for PUID/PGID. No chown or init container was added.	2026-08-24 21:01:53 +02:00
jlab-renovate[bot]	38ea281c96	Update docker.io/qmcgaw/gluetun Docker tag to v3.41.3	2026-08-24 14:34:52 +00:00
jklein	a37588c2fe	freesailarr: schema, null-safe fallbacks, seccompProfile, NOTES.txt ... Retrofits the repo-wide groundwork that #59 deliberately left out to keep the reviewed scope. Chart 2.0.0+up1.0.0 - a major, because seccompProfile changes runtime behaviour; appVersion stays the freely chosen marker 1.0.0. values.schema.json (#68). The largest schema in the repo: nine app blocks with probes, resources, security contexts, env and image. additionalProperties is false on every chart-owned level; the objects that go verbatim into the pod spec stay open. It rejects a mistyped app name, a mistyped key at any depth and ingress.domain - the key #59 removed, which until now would have been accepted in silence. Null safety (#99), both halves, because they cover different cases. The defaultedDict helper catches a key WITH a chart default, where Helm's coalescing deletes the null before the schema ever sees it; the widened ["object","null"] types catch a key WITHOUT one, where the null survives into validation. Measured on the old chart: radarr.securityContext: null rendered "securityContext: null" - the whole hardening gone - and securityContext.capabilities: null dropped the capability block entirely, so the container kept every default capability instead of dropping ALL. Both render green. The fallback table reproduces THIS chart's defaults including its deviations: the five linuxserver.io containers keep runAsNonRoot unset and a writable root filesystem so their s6 init can drop to PUID/PGID, flaresolverr keeps its numerically pinned uid, gluetun keeps NET_ADMIN, and recyclarr keeps its exec probes. Restoring the "clean" standard there would put the linuxserver containers back on the image's uid 911 - the failure calibre-web-automated hit. The sync between table and values.yaml is not left to discipline: rendering with every block of the silent class explicitly set to null is byte-identical to rendering the defaults, which is how a drift shows up. seccompProfile RuntimeDefault (#84) in the pod context, so it covers the init container too. Trivy's KSV-0104 drops from ten findings to none. NOTES.txt (#43) covering what actually bites: the pod is not Ready until the tunnel is up, the two fields the 1Password item needs, the warning when firewallOutboundSubnets is unset, the immutable volumeClaimTemplates, and the measured fact that imports do not hardlink across the media categories. Also, from point 5 of the plan: checksum/config does not apply - the chart has no ConfigMap - but checksum/secret-ref does, and was missing. Helm never sees the secret's contents, yet it does see which op:// item the OnePasswordItem points at, so repointing secrets.gluetunSecretRef now restarts the pod instead of leaving the old credentials running. README: the #43 status line was stale (it still claimed only homeassistant ships NOTES.txt), and the mandatory-icon rule now records freesailarr as a documented exception - #59 dropped the icon and did not amend the rule.	2026-08-24 16:06:20 +02:00
jklein	9cdbe097f6	Qualify the Docker Hub image names, drop the gluetun branding ... main qualified five charts' image references in 6c73ef8 on the same day this chart would otherwise arrive carrying the pattern that was just cleared out. The seven Docker Hub names now say where they come from: qmcgaw/gluetun, the five linuxserver.io images and the busybox init image, the last as docker.io/library/busybox since it is an official image. The three ghcr.io names were already qualified - checked rather than assumed. Verified with Renovate 44.41.0 in the official container (RENOVATE_PLATFORM= local, RENOVATE_DRY_RUN=lookup) that the prefixed form still resolves under the built-in helm-values manager, since that manager is the only thing keeping these images updated: it extracts all ten, datasource docker, no skipReason and no warnings, and returns concrete candidates for eight of them. A control run against the unqualified form produced byte-identical results, so the prefix changes nothing about what Renovate offers. Trivy's trusted-registry check (KSV-0125) drops from ten findings to none, which is what the registry list in ci/trivy/data/ksv0125.yaml documents as the point of writing images this way. Chart metadata: the icon was gluetun's logo and the description opened with a list of four of the nine projects, both suggesting a "main app" the stack does not have. The description now names none of them, and the icon field is omitted rather than filled with another project's logo - every other chart's icon is its one upstream's, and this chart has no such upstream. helm lint --strict notes "icon is recommended" as INFO and still exits 0. Rendered output differs in exactly the seven image prefixes and nothing else.	2026-08-24 15:23:35 +02:00
jklein	09fe3c2be6	Decouple appVersion from gluetun in wording and value ... The previous commit moved every image tag into values.yaml but left appVersion described as a marker "for the gluetun line", to be updated together with gluetun.image.tag. That still asserts a coupling the chart does not have, and the value v3.41.1 confirmed it at a glance. appVersion is now 1.0.0 (version 1.0.0+up1.0.0): the chart's own version marker, freely chosen and tied to no upstream. The texts say that instead of the old coupling in Chart.yaml, values.yaml and the two README passages. The README's remaining true statement is kept but generalized - renovate-bump-chart bumps the patch level on an unchanged appVersion for all nine images alike, which is not a gluetun special case. Also corrected on the way: the busybox init image comment claimed it was "pinned independently of appVersion (which tracks gluetun)". Neither half holds any more - appVersion tracks nothing, and every image in the chart is pinned the same way. No functional change: the rendered gluetun image is qmcgaw/gluetun:v3.41.1 before and after.	2026-08-24 15:10:14 +02:00
jklein	af5f9ed79b	Pin gluetun in values too, so Renovate proposes it there ... The chart bundles nine independently versioned upstreams, and eight of them were already pinned in values.yaml while only gluetun took its tag from appVersion. That split had no upside: it made gluetun the one image Renovate could not reach through the built-in helm-values manager, and it implied a "main app" the stack does not have. gluetun now carries gluetun.image.repository/tag like every other image, and the StatefulSet renders it from there. No tag comes from appVersion any more. Renovate picks all nine up through helm-values - the manager the repo already relies on for sidecar images - and ci/renovate-bump-chart.sh bumps the chart version with each update. Consequences, all documented where they bite: - renovate.json5 deliberately gets no app-version block for this chart. One would either duplicate the helm-values updates or rewrite an appVersion that selects no image. The absence is commented so it does not read as an oversight. - freesailarr leaves the change-app-version.yml choice list. That workflow rewrites appVersion and republishes, which for this chart would change no deployed image at all. - appVersion becomes a hand-maintained marker for the gluetun line. Since renovate-bump-chart.sh bumps the patch level on an unchanged appVersion, a gluetun update has to be paired with a hand edit of appVersion, or the +up suffix stops describing what the chart deploys. Noted in Chart.yaml, values.yaml and README.	2026-08-24 15:01:34 +02:00
jklein	d1933e0b53	Fix gluetun image tag: Docker Hub tags carry a v prefix ... The issue plan listed qmcgaw/gluetun:3.41.1, but the published tag is v3.41.1. appVersion is the exact image tag per the style guide, so appVersion becomes v3.41.1 and the chart version 1.0.0+upv3.41.1 (precedent: matrix-synapse, satisfactory, calibre-web-automated).	2026-08-24 13:41:46 +02:00
jklein	914c2d0205	Add freesailarr chart: gluetun-tunneled media automation stack ... Single-pod StatefulSet running gluetun (appVersion 3.41.1) as Wireguard VPN gateway with qbittorrent, prowlarr, flaresolverr, radarr, recyclarr, sonarr, seerr and bazarr sharing its network namespace. Config volumes via volumeClaimTemplates, media libraries as existing claims, per-app enable/ingress toggles, computed FIREWALL_INPUT_PORTS, hardened security contexts with documented per-image deviations. Wires up publish workflow, change-app-version choice, install-test exclusion and README overview.	2026-08-24 13:41:46 +02:00