16 Commits

Include renames

Author	SHA1	Message	Date
jklein	93fdb3eaea	sure: new chart for the we-promise Sure app (1.0.0+up0.7.4) ... One StatefulSet with two containers - the Puma web process and a Sidekiq worker - sharing one ReadWriteOnce PVC at /rails/storage. That shared volume is the reason they live in one pod: splitting them would need an RWX volume. Only the web container migrates, because the image entrypoint runs db:prepare solely for the './bin/rails server' command; the worker is started through args: so the entrypoint (and its jemalloc preload) stays in place and the two can never race. Probes are chosen for what they prove: liveness and startup use Rails' /up, which is a boot check and touches no database, while readiness uses '/', which runs User.count through authenticate_user! in self-hosted mode and therefore fails while Postgres is unreachable. The worker speaks no HTTP, so all three of its probes ask sidekiqmon whether this pod still holds a Sidekiq heartbeat in Redis. Three OnePasswordItem CRs (app, database, redis), ingress.domain kept required outside the Ingress because APP_DOMAIN and the WebAuthn relying party read it, strict values.schema.json, CI fixtures with throwaway Postgres 16 and Redis, and a Renovate manager on semver so the -alpha/-rc/-hotfix channel and the moving tags are never selected.	2026-09-26 21:08:55 +00:00
jklein	02b3c3ce75	renovate: align the config with cluster-config ... The shared jlab-renovate-bot instance serves this repo and cluster-config, and two repos behaving differently under one bot is a source of surprises rather than of safety. This adopts cluster-config's configuration: config:best-practices in extends, labels ["renovate"], no PR caps (prHourlyLimit 0, prConcurrentLimit 100), separateMinorPatch, an explicit dependencyDashboard, and global automerge with platformAutomerge. Two of those choices were previously wrong here and are now right, because the branch protection on main has caught up: a review requirement and validate-charts as a required check are both active. platformAutomerge therefore arms the PR on the forge and Gitea merges it when the check passes AND the review exists - the review is the gate, which is what makes automerging majors something other than unattended merging. Comments that asserted the opposite are rewritten rather than left to rot: the platformAutomerge: false comment ("not (yet) a required check on either side"), the "Majors stay manual" rule, the README PR policy bullets and the required-check paragraph, and the CLAUDE.md forge notes. config:best-practices pulls in docker:pinDigests, which is switched off again for custom.regex and helm-values: an appVersion: is a tag by construction and has nowhere to put a digest. Kept deliberately: minimumReleaseAge of three days on the routine updates (every merge here publishes a chart), the ignorePaths and ci/** opt-outs, every per-chart manager, the nginx and qbittorrent constraints, and postUpgradeTasks. Fixes #34	2026-09-22 19:44:28 +00:00
jklein	ae621746a1	Merge main into the MediathekArr branch ... The branch predates the Gitea move (#253) by 37 commits and both sides touched the same two files. Merged rather than rebased, so the signed commit of the original work stays intact, and resolved by combining rather than choosing - both statements are true at once: the chart has ten images now, and the repo lives on Gitea. README.md, the one real conflict: this branch rewrote the freesailarr image bullet from nine upstreams to ten, while main had grown a minecraft-server bullet next to it that this branch never had. Kept both - our "ten" wording and main's new bullet. renovate.json5 merged cleanly, but "cleanly" is not "correctly", so the result was read rather than trusted: the freesailarr exception now says ten and gained the pointer to the mediathekarr digest block, while the two things main added right beside it survived unchanged - the note that the post-upgrade hook is allow-listed on the shared Gitea instance, and the forge-neutral wording of the automerge rule. Nothing from before the move brought "GitHub" back into a sentence that had been made neutral.	2026-09-17 11:40:21 +02:00
jklein	c3889a66b6	Drop the Renovate workflow: the Gitea side already has a shared instance ... A measurement overtook this part of the change. A shared `jlab-renovate-bot` instance already runs on the Gitea side and already has this repository enrolled - its first run there opened PRs for searxng and gotenberg plus the dependency dashboard. A second runner in this repo would produce duplicate PRs and two schedulers rewriting each other's branches, so .github/workflows/renovate.yml is removed again. Two things fall out of that run, and both were open risks: - The instance reads our renovate.json5. searxng and gotenberg are customManagers targets of ours - no built-in manager finds an appVersion in a Chart.yaml - so the config is demonstrably in effect. - allowedCommands is already granted there. The searxng PR's diff carries `version: 1.0.4+up2026.9.11.ffe96f8a6 -> 1.0.5+up2026.9.13.96479fff6` next to the appVersion, and nothing but ci/renovate-bump-chart.sh writes `version:`. Had that allow-list been missing, postUpgradeTasks would have been skipped SILENTLY and every chart PR on Gitea would have been red on the version check with nothing naming the cause. With the workflow gone there is no container image to pin either; verified by dry run that the ghcr.io/renovatebot/renovate dependency is no longer extracted, while TRIVY_VERSION still is - that one belongs to the Trivy replacement and stays. README and CLAUDE.md now say Renovate runs on Gitea as an existing shared instance and that no workflow belongs here, so the next reader who finds none knows why instead of building one.	2026-09-16 15:49:36 +02:00
jklein	a6c27ebef3	Prepare the Gitea move: measured CI deviations, self-hosted Renovate, issue migration script ... Groundwork for #225, built on a throwaway pull request against the Gitea instance rather than on assumptions. The move itself is not part of this change - no Actions are switched off, no mirror is enabled, no branch protection is touched. What the probe run measured, and what follows from it: - Which jobs need a Docker socket: only the install-test. Measured per job - detect-changed-charts, build-chart, the quantity render and the Trivy config scan all pass on `ubuntu-latest`, which on that instance has no socket. The install-test dies there at "Create k3d cluster" with "Cannot connect to the Docker daemon", an error naming k3d and never the runner label. Its `runs-on` is now an expression: the label `ubuntu-docker` on Gitea, `ubuntu-latest` on GitHub, because the former does not exist there and a chart PR would otherwise queue forever during the handover. Gitea evaluates it - the probe job was taken by the docker runner. - The install-test still cannot pass on Gitea. That daemon is rootless with "Cgroup Driver: none"; the k3s node restarts immediately with an empty log because k3s needs cgroup delegation. The label is necessary and not sufficient, and the fix is the maintainer's. - aquasecurity/setup-trivy cannot be used on Gitea: it checks out aquasecurity/trivy from github.com with `github.token`, which there is a Gitea token, and ends on "could not read Username for https://github.com". Replaced by the release tarball - one request, same behaviour on both forges, green on the probe run. Also in this change: - .github/workflows/renovate.yml, Renovate in self-operation: a daily scheduled run in the official container, inert on github.com via a `github.server_url` guard. Every rule proved by dry run instead of assumed - the pinned Renovate image is tracked by the built-in github-actions manager (44.80.0 -> 44.87.1, minor), TRIVY_VERSION is still tracked after setup-trivy is gone (v0.72.0 -> v0.74.0, minor), and `ubuntu-docker` is not extracted by the github-runners manager at all, so nothing will quietly "correct" it. - ci/migrate-issues-to-gitea.sh, runnable, with --dry-run, and NOT run. Its header names what it cannot do: comment authorship, the #<n> references between issues, and attachments. - CLAUDE.md and README.md on the new flow: which forge and which tool, auto-merge on green checks in place of the merge queue Gitea does not have, and the measured differences of the two CIs. Refs #225 - deliberately no "Fixes": the move is not finished with this.	2026-09-14 17:07:31 +02: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
jklein	6b0d8c9232	ytdlp-web-player: new chart with an optional oauth2-proxy subchart (1.0.0+upv1.2.0) ... Deploys matszwe02/ytdlp_web_player, a Flask app that fetches videos with yt-dlp, transcodes them with ffmpeg and serves them as HLS. It ships no authentication of any kind, so the chart carries a preconfigured oauth2-proxy as an optional subchart, in the data path in front of the app. This is the first chart in the repo with a dependency, so the rule "charts have no dependencies" falls here. It is replaced in CLAUDE.md and README.md by a bar: a dependency has to be optional and off by default, upstream's chart is consumed as it comes (documented where it falls short of our conventions, never patched), and the price is written down - above all that a subchart is invisible to everything downstream watching Helm release versions, so a new proxy release only reaches a cluster when this chart is republished. CI learns the dependency in five places, not the three the plan expected: helm lint, package, template and install all exit 1 while charts/ is unfilled, so ci/helm-dependencies.sh runs before lint and package in validate-charts.yml, before package in publish-helm-chart.yml, and inside run-install-test.sh, run-trivy-config.sh and run-quantity-render-test.sh - the last of which renders every chart on every PR and would have gone red first. Notable chart decisions, each measured rather than assumed: - The image has no USER and runs as root by default, but not by necessity: it runs under an arbitrary uid with readOnlyRootFilesystem and the full hardening baseline. Only the pinned uid is a deviation, and it is documented. - Two emptyDirs, each justified separately. /data holds the video cache (DATA_PATH). /tmp is NOT mounted - measured across metadata extraction, HLS transcoding, sprite generation and audio extraction, the image never writes there. What it does write is $HOME/.cache, so /cache is mounted with HOME and XDG_CACHE_HOME pointed at it; without it yt-dlp re-downloads its JavaScript challenge-solver from github.com on every extraction. - The proxy is wired through config.configFile, the only value the subchart passes through tpl - config.upstreams is emitted with toJson and would carry a literal {{ .Release.Name }} into the manifest. - Rendering aborts when this chart's Ingress and the proxy's claim the same host: ingress-nginx rejects the second one and a Fleet bundle then sits in ErrApplied until forceSyncGeneration is bumped. Fixes #214	2026-08-30 17:34:49 +02:00
jklein	8df1913c5c	bentopdf: new chart for the PDF toolbox (1.0.0+up2.8.7) ... BentoPDF computes entirely in the visitor's browser; the container only serves static files through nginx. The chart is therefore close to cyberchef - same nginx-unprivileged base, uid 101, port 8080, probes on "/" - with four differences that shaped the design. Runtime config.json. The one setting reachable at runtime is the tool list. It is a static file in the middle of the web root, so it is mounted by subPath: a directory mount would hide the whole application. subPath mounts are never refreshed by the kubelet, which makes the checksum/config annotation (#82) load-bearing rather than decorative. bentopdf.config is passed through verbatim, like searxng's settings, so a key upstream adds tomorrow is a values change and not a chart change. Three env switches that would kill the pod. PORT, DISABLE_IPV6 and ROBOTS_NOINDEX are implemented as "sed -i" against files in the image, run under "set -e" in /docker-entrypoint.d/, and the base image's entrypoint aborts when one of them fails. With readOnlyRootFilesystem: true the pod therefore never starts instead of ignoring the switch - measured in k3d as CrashLoopBackOff, exit 1, "sed: can't create temp file '/etc/nginx/nginx.confXXXXXX': Read-only file system". None of the three is offered as a first-class value; values.yaml names the failure picture and the escape hatch (env block plus readOnlyRootFilesystem: false). Writable paths were measured, not copied from the upstream chart. /etc/nginx/tmp holds the pid file and /var/cache/nginx is where nginx creates its temp directories at startup - without it the master aborts with 'mkdir() "/var/cache/nginx/client_temp" failed'. /var/run is deliberately not mounted: the running pod proves it is unnecessary. Everything else about BentoPDF is a build-time argument and out of reach for any chart; values.yaml says so explicitly rather than leaving it to be discovered. Two accepted consequences are named there too: some tools fetch WASM modules from a public CDN at runtime, and the served pages carry a canonical link to the vendor's site. Fixes #174	2026-08-28 18:22:30 +02:00
jklein	46942db53a	searxng: new chart (1.0.0+up2026.8.22.9fea41204) ... SearXNG as a stateless Deployment plus a settings ConfigMap, with the four CI steps a new chart needs: publish workflow, change-app-version choice list, ci/searxng/ fixtures and a renovate.json5 block. Three points where the chart is not a cyberchef with another name: * The image entrypoint writes settings.yml into /etc/searxng only when the file is missing. The chart always mounts one by subPath, so the copy and the random-secret sed never run and the container needs no write access there - which is what allows readOnlyRootFilesystem: true. * The signing key is a required OnePasswordItem, not a ConfigMap key. It signs the settings cookie and the image-proxy URLs, and the entrypoint's self-generating fallback cannot fire here, so without it the instance would run on the literal "ultrasecretkey" - which webapp.py refuses with exit 1. * All three probes use /healthz, the only path the bot detection lets through unconditionally. Measured: with the limiter active, "/" answers 429 while /healthz still answers 200. ingress.domain is read a second time outside the Ingress template, for SEARXNG_BASE_URL, and carries its own required() there - so it stays mandatory with the Ingress switched off. The Renovate versioning regex deviates from the plan on the issue and matches the commit hash WITHOUT capturing it. Renovate parses a "build" group with Number.parseInt, so a hash becomes the digits leading it; measured on renovate 41.173.1 and 44.48.0, the planned form reports an image pushed earlier the same day as an update to a newer one. Reasoning in the block and in README.	2026-08-27 21:09:59 +02:00
jklein	f5da9ce126	renovate: exclude the two legacy qbittorrent tags ... linuxserver/qbittorrent still carries 14.3.9 and 20.04.1 from earlier tagging schemes. Docker versioning sorts both above every real release, so Renovate offers them as major updates - PRs #152 and #153 are exactly those, and they would have to be closed by hand again after every lookup. They cost more than the noise. Renovate fills the major bucket once, so while a stray occupies it the genuine major is never offered at all: measured from currentValue 4.6.4, the unconstrained lookup returns 4.6.7 and 20.04.1, and never mentions 5.2.3. Both are excluded by name. A bound such as "<10" would reject a genuine major sooner or later, whereas two finished artifacts cannot grow and so cannot mask a release that does not exist yet. A shape-based filter was tried first and measured out: requiring a non-padded minor drops 20.04.1 and simply promotes 14.3.9 into its place. Verified with renovate 44.41.0 (dry-run=lookup) against the live registry: currentValue 5.2.1 -> [5.2.3 (patch)], both strays gone currentValue 4.6.4 -> [4.6.7 (patch), 5.2.3 (major)] The second fixture is the guard the nginx rule taught us to run - it proves the filter does not silently empty the update list. A full run over the real repository with the real config confirms it in place: qbittorrent offers 5.2.3 only, nginx is unchanged, and no docker dependency carries a skipReason or a warning.	2026-08-24 15:45:57 +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	0d62c0d6ce	renovate: name the nginx alpine check in #84 accurately ... The rationale called the alpine switch a proposal from the issue text. A later comment on #84 commissions it as a check with a defined scope (nginx.conf compatibility, port 8080, uid 101, /tmp redirection) to be done alongside the seccompProfile PR for this chart. The outcome is open, the check is not - the constraint has to survive either way.	2026-08-24 12:18:29 +02:00
jklein	2d03ba8a7c	renovate: let the nginx constraint survive a variant tag ... The anchored form rejected any tag with a suffix. Docker versioning only offers candidates carrying the current tag's suffix, so the day the delegation sidecar moves to a slimmer base image (#84, still open) every candidate would fail the filter and nginx would stop receiving updates - without an error, a warning, or a red dashboard. Verified against currentValue 1.28.0-alpine: anchored form returns "updates": [] and "warnings": [], the suffix-tolerant form proposes 1.30.4-alpine and still refuses the newer 1.31.x mainline.	2026-08-24 12:15:01 +02:00
jklein	0908785b10	renovate: keep the delegation nginx on stable branches ... nginx numbers its release branches by minor: even is stable, odd is mainline. PR #139 proposed 1.30.4 -> 1.31.4, which would have moved the Synapse delegation sidecar onto mainline without that ever being a decision. allowedVersions now permits even minors only; patch updates inside the stable branch still come through and still automerge.	2026-08-24 12:09:26 +02:00
jklein	2e0e37d838	renovate: automerge minor updates, make the install-test blocking ... The two open Renovate PRs (#138 alpine 3.22 -> 3.24, #139 nginx 1.30.4 -> 1.31.4) never automerged because both are minor updates while the rule only covered patch and digest. Sidecar images barely move in patch steps, so patch-only would practically never fire. Automerging a chart update publishes it, so the install-test can no longer report failures without blocking: continue-on-error is gone and issue #22's stabilization phase ends here. Majors stay manual.	2026-08-24 12:01:08 +02:00
jklein	6b25d082a7	renovate: chart-aware config with an automatic version bump ... Renovate only ever rewrites appVersion or an image tag, so every PR it opened against a chart directory failed the build-chart version check (#138, #139). ci/renovate-bump-chart.sh recomputes version: <semver>+up<appVersion> as a postUpgradeTasks hook: chart major when the app major moves, chart patch otherwise. Each chart renders its main image as <repo>:{{ .Chart.AppVersion }}, so repository and version live in different files and Renovate cannot join them. The mapping is one customManager per chart in renovate.json5, deliberately not a comment inside each Chart.yaml - that would touch all 20 chart directories and force 20 publishes for a comment change. Patch and digest updates automerge after a 3-day minimumReleaseAge once the pipeline is green; majors arrive one line at a time to match the stepwise app-major procedure. ci/** stays excluded: the install-test fixtures pin throwaway infrastructure to major lines on purpose.	2026-08-24 11:42:43 +02:00