608 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
jlab-renovate-bot	a051e3c6d7	Pin dependencies	2026-10-02 00:43:38 +00:00
jklein	f284d209f7	sonar: correct the project key, and record what the first run measured ... The project key was a guess. The project exists in SonarQube as JLab-Helm-Charts; jlab-cluster_helm-charts was reasoned from the instance serving two owners, and it produced the one error message that covers both a non-existent project and a token without permission on it: ERROR You're not authorized to analyze this project or the project doesn't exist on SonarQube and you're not authorized to create it. Because the server does not distinguish those two cases, the next occurrence of that message now means the token lacks "Execute Analysis" - which is worth a comment in the file rather than a second round of guessing. sonar.projectName goes away entirely. Once the project exists on the server the display name belongs to the server, and a name sent with every analysis would overwrite a rename there on every run, silently. The reason is a comment in the file so the line is not added back as an obvious omission. The README analyser table was built from SonarQube's language list and promised more than this instance delivers. Measured in run 375: two quality profiles loaded, json and yaml; the IaC Kubernetes sensor (3.4 s) and the secrets detection over all 391 indexed files did the work. Shell and GitHub Actions did not run, and no configuration here can make them - analysers are server-side plugins. The consequence is now stated: the five ci/ scripts and the thirty workflow files, the files carrying the actual logic, are not analysed at all. Whether the instance gains those plugins is a decision outside this repository. Run 375 also answered the three questions this path carried, all positively: node24 is in the runner image, the ~59 MiB scanner download and its signature arrived in roughly three seconds (so the MTU failure that once killed a 17 MB download does not repeat), and a repository variable does reach a workflow called from another repository - which settles the identical question the publish route carried for OP_CONNECT_HOST. The publish route's upload is still unproven and stays listed as such. Fixes #74	2026-10-02 00:15:06 +00:00
jklein	67d8c94fb3	ci: call the shared SonarQube block, and say what it does not do ... Adds the caller side of the analysis: .github/workflows/sonar.yml as a hull of the same kind as the publish ones, and sonar-project.properties as the project-specific half. The workflow itself is the shared block in workflow-util/pipelines, bound to @v4. No paths filter, unlike the publish hulls: the analysis looks at the whole tree - the five shell scripts under ci/, every workflow file, the YAML and Helm templates, the values.schema.json files, and the secret detection over everything. A filter would leave the previous result standing after a change it did not cover while still presenting it as current. workflow_dispatch is on the hull on purpose. Three things about this path are unmeasured - node24 in the runner image, the ~59 MiB scanner download, and whether a repository variable reaches a workflow called from another repository - and any of them may need more than one attempt. Without a dispatch every attempt would cost a dummy commit on main. No exclusions, including the Helm templates, which are not valid YAML because of {{ }}. What the Helm and YAML analysers make of them is only learnable by letting them run over them once, and an exclusion written on a guess hides whatever else matches it. If the first run produces noise worth suppressing, the exclusion belongs in sonar-project.properties with the finding it answers named next to it. The project key carries the owner (jlab-cluster_helm-charts) because the instance serves two, and a key cannot be changed afterwards without losing the project's history. The analysis is not a gate. The Community Build analyses the main branch only, so the trigger is a push to main and a finding appears after the merge - at which point there is nothing left to block. README and the CI-CD wiki page both say so, with the two conditions under which a gate would become right, so that its absence is not read as an oversight.	2026-10-01 23:49:48 +00:00
jklein	8878329f31	ci: publish charts through the shared block in workflow-util/pipelines ... The reusable publish workflow now lives in workflow-util/pipelines and is called pinned to @v3. All 25 thin hulls switch over and our copy is deleted in the same commit: a hull pointing at a deleted file, or an orphaned file nobody calls, would both be worse than the state before. Each hull gains one line, registry-owner: ${{ github.repository_owner }}. The owner used to be derived inside the workflow (#63); as a required input without a default it is evaluated here, in the calling repository, where the value is measured. That is the house rule of pipelines - a shared block never guesses an owner segment - and it keeps the block free of any context semantics. The workflow_dispatch and push triggers of every hull are untouched; after the move the dispatch is the only way to trigger a publish by hand. The Connect host is no longer wired into the block. It reads the repository variable OP_CONNECT_HOST, which the maintainer has set, and fails in its first step naming the variable when it is empty. Documentation follows the same split as the code. The README entry no longer describes a workflow of this repository; it names where the block lives, what each caller owes it, and points at the publish-helm-chart page of that repository's wiki for the reasons behind the upload step, which are no longer ours to keep current. Nothing of them was lost in the move - the upload step's shell body went across unchanged apart from two error messages that name the owner as an input. Also corrected, because the move made them wrong rather than merely stale: - the helm-dependencies.sh entry still counted the local publish workflow among the five places it runs; it is still five, one of them now the shared block, which is why that block names the script as a prerequisite of its callers; - two comments in install-test.yml pointed at publish-helm-chart.yml as a sibling file, one of them for a trap it documented "at length" - that long form is now on the pipelines wiki, and the comments say so; - the hull count read 24, and reusable workflows with secrets: inherit are now confirmed to work across repositories too; - the chart-creation step in CLAUDE.md said the reusable workflow is ours. install-test.yml stays here, with the reason written down (decision 4 on the issue): it is reusable in form but welded to the ci/ fixtures, the exclusion parser and this repository's chart matrix. A block only one repository can use is not shared, only moved. The note is there so the question is not asked again. Fixes #66	2026-10-01 23:01:47 +00:00
jlab-renovate-bot	f3ad3a9844	Update urlaubsverwaltung/urlaubsverwaltung Docker tag to v6.14.0	2026-09-30 18:57:54 +00:00
jklein	b614b53602	ci: remove the temporary repository_owner probe, record the measurement ... github.repository_owner is populated on this Gitea instance: measured as "jlab-cluster" (12 characters) in run 282 of validate-charts.yml. The value is now in the comment above the upload step, so the fact survives without the step that produced it.	2026-09-30 18:51:55 +00:00
jklein	a12983fbea	ci(publish): compose the registry URL from a base and the repository owner ... charts-url in op://GitHub-Actions/jlab-registry-access held the full registry URL and publish-helm-chart.yml appended /api/charts to it. It now holds only the base up to /api/packages, and the owner segment comes from github.repository_owner, so the target is composed as <base>/<owner>/helm/api/charts. Nothing in this repository points at the registry any more, not even a path segment, and the second owner on the same instance needs no second setting. The 26 thin publish-<chart>.yml callers are unchanged. Two guards keep the switch from the old shape loud rather than a 404 against a masked URL: charts-url is rejected unless it ends in /api/packages, naming /helm, /api/charts or an included owner explicitly; and the derived owner is rejected when empty or when it is not a usable URL path segment. Everything the upload step already had is untouched - the per-field :? guards, the whitespace check on the credentials, the host masking, the built file name, --fail-with-body. The probe step in validate-charts.yml is temporary and measures whether this forge populates github.repository_owner at all; it is removed again once the value has been read off the run.	2026-09-30 18:49:56 +00:00
jklein	61e28a1459	docs: the instructions block is a snapshot from session start ... The first wording said the project-instructions block "is read from the spawning session's working directory", which suggests that pulling in that directory fixes it. It does not. The block is a snapshot taken when the spawning session started, and nothing re-reads it afterwards. Measured: a session whose working directory had been fast-forwarded to the tip immediately before, and verified as up to date, still handed the next agent a block from before Gitea #47 — while that agent's own worktree was identical to origin/main (0 0). A current checkout and stale instructions at the same moment. Hence the two consequences that actually hold: the directory must be current before the session starts, and an agent checks a rule against the file in its own worktree and the diff against origin/main, because the first cannot be enforced from inside an agent and the second can.	2026-09-27 23:05:06 +00:00
jklein	56bed94064	docs: cut every worktree from a freshly fetched origin/main ... A worktree branched from the local main ref can be arbitrarily old, and the staleness is invisible where it costs most: the project-instructions block a subagent receives at the head of its context is read from the spawning session's working directory, not from origin/main. An outdated worktree therefore hands every agent rules that were already corrected. Measured on 2026-09-27: an agent reported a contradiction in CLAUDE.md that two PRs had already fixed, and quoted the stale copy as binding. Nothing broke only because the same agent compared its diff against origin/main rather than against the local pointer. The same day, in the shared checkout, main..HEAD showed 105 differing files while the difference against origin/main was one line. Also name the wiki's default branch: it is main, not master. Since the rule to fetch and rebase before every wiki push, the name is required — an agent tried to rebase onto origin/master and the rebase failed. Fixes #57	2026-09-27 22:58:39 +00:00
jklein	5c513291a8	docs: a PR that does not finish its issue writes Part of #n, not Fixes #n	2026-09-27 22:02:32 +00:00
jklein	6a3b05503e	Make the all-charts install-test repeatable, as one shared job ... The install-test matrix follows the charts a pull request changes, so a chart nobody has touched since the forge move carries a green history from a different runner - and that green says nothing about today. Gitea PR #48 showed what the answer is worth: correcting a comment in 21 charts made every one of them "changed" and turned the run into the first all-charts install-test after the move, 19 of 20 matrix charts Ready in 12m41s and exactly one not (rss-bridge, Gitea #51). By accident. The install-test job moves into the reusable .github/workflows/ install-test.yml and is called twice: by validate-charts.yml with the charts a pull request changed, and by the new install-test-all-charts.yml with all of them. Not copied for the second caller - a second copy is a second chance to test differently, unnoticed, which is the argument that gives ci/excluded-charts.txt exactly one parser. The parts that would drift are the ones that were paid for once already: the pinned kubectl with its skew check, envsubst, the containerised-job detection, the per-leg cluster name. Nothing about how a chart is installed changed. The moved job differs from its predecessor in the matrix source (inputs.charts instead of the detect job's output), an id on the install step, and a step that records the result; every other step is byte-identical. The all-charts run is workflow_dispatch only - a schedule would spend compute every day on a question that changes rarely - with an optional subset input, which is what lets a single chart be tested against the runner as Gitea #51 needs. One throwaway cluster per chart, no reuse: reuse saves time and changes what the test proves. An unknown or excluded chart name, and an empty matrix, are loud errors rather than a green run over nothing. Every leg writes its own outcome into the job summary next to the four facts that decide what the outcome means - date, runner label, K3S_IMAGE, kubectl version - and a final job records the verdict over the matrix. A green run nobody notes is unknown again next time. The excluded charts appear with their justification, from the one parser, as in the pull request pipeline. 20 charts in 12m41s is written down as the expectation, so a later deviation is visible as one. Fixes #52	2026-09-27 14:30:39 +00:00
jklein	813c796a7b	feat(valkey): one Valkey instance per application (1.0.0+up9.1.2.alpine) ... A new chart for a single Valkey instance per application, replacing the shared cluster-redis whose separation rests on one ACL file in one 1Password field - a construction in which every change touches six applications and which cost a month of Paperless standstill. Shape: StatefulSet with one replica, ClusterIP Service, no cluster mode, no Ingress and no value to add one. The password arrives as a finished configuration line ("requirepass <secret>") in the 1Password field auth-conf, is mounted as a file and included by the main configuration - never in argv, never in the environment. The include is rendered last, so nothing in extraConfig can override it. Because a misspelled or empty field would leave an open server that looks perfectly healthy, an init container greps the mounted file for the line and refuses to start the pod without it; it never prints the file. maxmemory is derived from the computed memory limit (maxmemoryFactor, default 0.75) and a configured value above that limit aborts the render: otherwise the kubelet's OOM kill decides what the eviction policy was configured to decide. Persistence and eviction are documented as pairs - queue (PVC + noeviction, the default) and cache (emptyDir + allkeys-lru) - and the combination "no persistence + noeviction" carries a warning in values.yaml and in NOTES.txt. Probes: valkey-cli ping as an exec probe, authenticated through VALKEYCLI_AUTH read out of the mounted file, with "-e" and an assertion on the answer PONG. Without -e valkey-cli exits 0 on an error reply (valkey 9.1.2, src/valkey-cli.c: the config.set_errcode branch in cliReadReply), which would make the probe unable to fail. Hardening: uid 999 / gid 1000 - the image's own valkey user - with fsGroup matching, runAsNonRoot, readOnlyRootFilesystem, all capabilities dropped and seccompProfile RuntimeDefault in the pod context so the init container is covered too. /data is the only writable path. NetworkPolicy on by default (first chart in this repo with one), with a switch and a list of additional namespaces; values.yaml names that it is only a boundary where the CNI enforces policies. Wiring: publish-valkey.yml, the chart-name choice list, ci/valkey fixtures for the persistent variant, a plain docker-versioning Renovate block, README chart row.	2026-09-27 11:24:55 +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
jlab-renovate-bot	9df2b68ed9	Update ghcr.io/paperless-ngx/paperless-ngx Docker tag to v3.2.1	2026-09-26 22:04:00 +00:00
jklein	733fea5d9e	docs: point the two workflow cross-references at the right steps ... Moving the wiki step from 7 to 5 shifted the two items behind it, and the references that name them by number stayed where they were. The wiki section still called itself step 7, and the auto-merge bullet cited rule 6 for "the user merges", which is rule 7 — rule 6 is the agent's lifetime. A number pointing at the wrong step is the kind of reference that passes for a reason on the next reading, so both are corrected here rather than in an issue of their own.	2026-09-26 21:46:03 +00:00
jklein	1d3bacfb12	docs: name the remote that exists, and a push rule for the wiki ... The remote bullet described two remotes, github and JLab-Git, and denied that origin exists. The checkout has exactly one, origin, pointing at the Gitea instance, and so does every worktree cut from it; two agents lost time on the difference. The point the bullet made survives — Gitea is the leading copy, the mirror is fed from there, and where a second remote does exist the advice to name it still holds. The wiki has no PR flow, so parallel edits meet only at push time. During Gitea #16 and #18 two agents edited the same two pages minutes apart and the rebase happened to be clean; a force push would have deleted the other edit with nothing to report it. Fetch and rebase before every push, never force-push. The chart pages no longer quote versions, so the sentence that explained them as snapshots now says they carry no numbers at all. That change is already in the wiki.	2026-09-26 21:43:14 +00:00
jklein	8074ed14a5	Guard the four unguarded OnePasswordItem references with required() ... calibre-web-automated 7.0.0, minecraft-server 6.0.0 and urlaubsverwaltung 10.0.0 each majors: an installation that renders today with an empty itemPath stops rendering. searxng 1.0.6 is documentation only - its valkey reference is correctly optional and stays gated by {{- if }}. Every message names the values path. values.yaml now says per key why it is required, reusing the wording the charts' NOTES.txt already carry. The hand-rolled "cwaSecretRef IS UNSET" block in calibre-web-automated's NOTES.txt is gone: after the guard the render aborts first and that block is unreachable. minecraft-server's note stays true and now points at the guard. No "required" array in the schemas, and README guideline 12 now says why. The plan called for one; measuring it showed it could never fire: the key ships as null, so it is present at validation time, and JSON Schema's required tests presence, not null-ness. Making it fire means either dropping the null default or narrowing the type to "string", and both turn helm lint --strict red on the chart's own defaults. The schema therefore describes the key as required and required() enforces it. The README bullet on how null reaches the schema was also wrong in the case it was being applied to - a null chart default is not coalesced away - and now distinguishes the three cases. searxng: the claim "charts in this repo have no dependencies (README, guideline 13)" in the valkey template, in values.yaml and twice in _helpers.tpl has been false since #214 and cited the wrong guideline; dependencies are admissible and are guideline 14. The same sentence survives in other charts' helpers and needs its own round.	2026-09-26 21:15:30 +00:00
jklein	d9267b2180	sure: fix the readiness probe, the ephemeral-storage budget and HOME ... Second install-test run, three findings, all measured: - Readiness on "/" failed with "http: server gave HTTP response to HTTPS client" on a pod that was answering correctly. The kubelet's HTTP prober follows redirects to the same host, and with RAILS_ASSUME_SSL=true the app builds its redirect as https://<pod-ip>:3000/registration/new, which Puma does not speak. The probe now runs curl without -L and accepts 2xx-3xx itself. The same log also proves what the probe is for: against an empty database the redirect target was /registration/new, the branch User.count decides, so the path really does reach Postgres. - The pod was evicted within two minutes of every start: "ephemeral local storage usage exceeds the total limit of containers 60Mi". emptyDirs and the stdout log both count there, and the image rebuilds its Bootsnap cache under /rails/tmp on every start because the emptyDir hides the one baked into the image. The request is now 256Mi (limit 768Mi) per app container - headroom, not a measurement. - /home/rails is read-only, so Bundler created a throwaway home under TMPDIR on every invocation, worker probe included. HOME now points at a directory the init container creates. The CI postgres fixture gets -d sure on its readiness probe, so the server stops logging a missing database that nothing asked for.	2026-09-26 21:08:55 +00:00
jklein	a414af089d	sure: give Ruby a temporary directory it accepts ... The first install-test run failed with both containers crash-looping during boot: system temporary path is world-writable: /tmp /tmp is world-writable: /tmp . is not writable: /rails ArgumentError: could not find a temporary directory raised from MiniMagick, which Active Storage loads while Rails boots. Ruby's Dir.tmpdir skips a candidate that is world-writable without a sticky bit, and a Kubernetes emptyDir is created mode 0777 with no sticky bit - so with a read-only root filesystem there was no candidate left. A tiny init container, the app's own image running as the same non-root uid and with no capability added, now creates one private subdirectory (mode 0700) inside each tmp emptyDir, and both containers run with TMPDIR pointing at it. Creating an entry in a 0777 directory and chmod'ing what one just created needs no privilege, so the hardening standard holds unchanged.	2026-09-26 21:08:55 +00:00
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
jlab-renovate-bot	819d7b2cf7	Update urlaubsverwaltung/urlaubsverwaltung Docker tag to v6.13.1	2026-09-26 20:41:42 +00:00
jlab-renovate-bot	7115eb87f2	Update lukevella/rallly Docker tag to v4.15.2	2026-09-26 20:41:20 +00:00
jlab-renovate-bot	9344a45992	Update teamspeaksystems/teamspeak6-server Docker tag to v6.0.0-beta13.1	2026-09-25 16:01:36 +00:00
jklein	4715d85b99	satisfactory: server.storage stays the documented exception (#39) ... Walks back the one part of the previous commit that changed rendered output: storage was pulled into the server fallback, so an erased size fell back to 20Gi instead of rendering a PVC without one. values.schema.json had documented the opposite decision - "an erased value yields an invalid PVC rather than a silently degraded workload" - and that is someone's reasoned trade, not collateral of the nil-pointer bug next to it. Overturning it inside a patch would have made this the only release where valid values render differently, and it would have settled an open design question in a PR nobody opened for that. It goes to #39 instead. So storage is out of the defaults again and the schema note is restored verbatim, extended only by where the exception is argued. values.yaml marks it as the one key of the block that is deliberately not null-safe. The README rule that had leaned on this example now says the thing that actually holds: an exception is fine, an unmarked one is not. Everything else stands - dev and server null-safe, the single-key findings on the ports, formatNumber against exponential notation, 7.0.1. Re-measured after the walk-back: rendered output against the chart defaults and against a full override set is byte-identical to 7.0.0, NOTES.txt included, and "--set server=null" now renders exactly the sizeless PVC that "--set server.storage=null" rendered on 7.0.0.	2026-09-23 20:45:24 +00:00
jklein	5ff6e401c7	satisfactory: dev and server fall back instead of aborting (7.0.1) ... --set dev=null aborted the render at .Values.dev.debug and --set server=null at .Values.server.replicas, while the third block, game, has fallen back to the chart defaults since 7.0.0. Half-safe is the worse state of the two: whoever sees game=null work assumes server=null does too. Both blocks now run through satisfactory.defaultedDict like game, via two new helpers next to it. server.resources is deliberately NOT re-defaulted there - it already runs through satisfactory.effectiveResources, which carries those defaults and is null-safe on its own, and a second copy of limitFactor: 2 / 4Gi / 1 / 5Gi would be a third place for them to drift. server is read in four files, not one, and the fourth is NOTES.txt, which helm template never renders - a fix confined to the manifests would have looked green and still aborted on a real helm install. All four go through the helpers. The single erased key was the quieter half of the bug and is fixed with it: a nulled server.gamePort rendered "port:" and "nodePort:" empty into the Service and an empty containerPort into the StatefulSet, and a nulled server.storage a PVC asking for no size - manifests rejected by nothing until the API server saw them. server.storage was documented in values.schema.json as deliberately not null-safe; that reasoning does not survive the block-level case, because it made "server: null" render a sizeless PVC instead of falling back like everything else. The schema note is replaced rather than left lying. Rendered output for valid values is unchanged: helm template against the chart defaults and against a full override set is byte-identical to 7.0.0, and so is NOTES.txt. Hence a patch bump, appVersion untouched. Fixes #16	2026-09-23 20:45:24 +00:00
jlab-renovate-bot	8074e0de59	Update teamspeaksystems/teamspeak6-server Docker tag to v6.0.0-beta13	2026-09-23 04:02:38 +00:00
jlab-renovate-bot	1edcf6fb9c	Update urlaubsverwaltung/urlaubsverwaltung Docker tag to v6.13.0	2026-09-23 01:02:41 +00:00
jlab-renovate-bot	c36c5ee2c5	Update itzg/mc-router Docker tag to v1.47.1	2026-09-22 22:02:23 +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
jlab-renovate-bot	ddbf82e0d4	Update urlaubsverwaltung/urlaubsverwaltung Docker tag to v6.12.1	2026-09-18 16:02:15 +00:00
jklein	5b13569948	docs: the Coder workspace is the normal case, so tea runs without op ... Work on this repo happens in a Coder workspace that has no 1Password CLI. The rule that tea may only be called as 'op plugin run -- tea' therefore described an environment that no longer exists here, and following it meant either waiting for a tool that is not coming or ending with a pushed branch and no PR. tea is now called directly. It carries the workspace's stored login, so what it opens is authored by the bot account - accepted, and named in the report when it happens. The older instruction is kept for machines that do have op. Signing needed the same correction: it runs through the workspace's own SSH signer, not op-ssh-sign, and the check is 'git log --format=%G?' printing G.	2026-09-18 11:20:46 +00:00
jklein	feb70cf1e4	docs: order the wiki step before the merge, not after it	2026-09-18 08:49:24 +00:00
jklein	03bb454eb7	docs: make the wiki the knowledge base and its upkeep a required step ... The wiki now carries one page per chart (prerequisites, installation, the required 1Password fields, the complete values reference and the chart's traps) plus the workflow, the pipelines, versioning, Renovate, the style guide and the incidents behind each rule. README points at it and keeps its own role: the overview for someone reading the code, while anything an operator needs lives in the wiki. CLAUDE.md gains the wiki edit as step 7 of the mandatory workflow, with a table of what obliges an edit - and the one thing that does not, a plain app-version bump, since Renovate automerges those and never touches the wiki. Also corrects the patchmon row: the 2.x server serves frontend and /api/* from one process, so the chart renders one Deployment plus an optional guacd sidecar, not two Deployments.	2026-09-18 08:48:34 +00:00
jklein	afa1efb598	Merge pull request 'freesailarr: MediathekArr as the tenth container, off by default (3.1.0+up1.0.0)' (#25) from feat/freesailarr-mediathekarr into main	2026-09-17 15:19:01 +00:00
jklein	60670182ff	docs: describe what is, now that the move is done ... The documentation still described a migration in progress, and the worst line claimed the install-test "cannot run on Gitea at all" - true two days ago, the opposite of true now, and exactly the sort of sentence someone builds a wrong assumption on. README and CLAUDE.md now state what holds: everything runs on Gitea, github.com is a mirror with Actions and Renovate off, branch protection with a signature requirement is active, and the tool is tea. The move itself is not retold - that is Gitea #14. "Where this repo lives" keeps its place but turns around: it is no longer a list of what blocks us, it is what a Gitea runner does differently from a GitHub one, with the measurements. Newly written down because it holds permanently and stood nowhere: a matrix runs concurrently in ONE job under ONE status context, so a required check per chart is impossible and the context name carries the unexpanded matrix expression; expected runtimes, so a later deviation is visible as one, with the note that the difference to GitHub is structural - one runner for both legs against a VM per leg - and not performance. The six assumptions a GitHub runner had been meeting quietly are split rather than listed. Five are environment (MTU, fs.inotify, missing kubectl and envsubst, kubeconfig on 0.0.0.0): they fail loudly, say nothing about our code, and are fixed on the node side. The sixth gets its own block because it is the one that does say something about our code - the hard-coded k3d cluster name was wrong on GitHub too and only never showed there, because a VM per matrix leg meant two legs never saw each other. A generous environment is no friend when you want to know whether something is correct. Two rules generalised out of this round, as rules rather than as a story: a check that a broken system passes is worse than no check (with the two vacuous forms that caused it), and green does not mean checked, pointing at Gitea #24 as an open case of the same kind - explicitly not claimed as solved. Also fixes a hazard the move created: most #n in these files name closed GitHub issues that were never migrated, while Gitea resolves a bare #n against its own counter - #22 there is an unrelated throwaway pull request, not the install-test issue the text means. Stated once at the top instead of rewriting sixteen references into numbers that do not exist.	2026-09-17 17:13:39 +02: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
jlab-renovate-bot	82b90475ce	Update lukevella/rallly Docker tag to v4.15.1	2026-09-17 08:35:15 +00:00
jklein	87221abf29	Merge pull request #253 from jk-cluster/chore/gitea-migration-prep ... Gitea-Umzug vorbereiten: gemessene CI-Abweichungen, Renovate im Eigenbetrieb, Issue-Migrationsskript	2026-09-17 07:47:21 +00:00
jklein	fdd798e1d9	install-test: provide envsubst, and say why it is not pinned like kubectl ... ci/run-install-test.sh renders ci/<chart>/fixtures.env.yaml with envsubst. GitHub's hosted image ships gettext-base, the Gitea runner image does not, and without it the fixtures collapse to 'error: no objects passed to apply' - gluetun never gets its Wireguard key and nothing behind its kill switch becomes Ready. The script is left untouched; it does nothing wrong, a standard tool is simply absent. Checked for rather than pinned, and the difference from kubectl is written next to it: kubectl's version changes what the test MEANS, because its distance to the API server is a real source of failure, so it is pinned, tracked and guarded. envsubst substitutes text and the release performing it does not change the result, so a pin would be upkeep without value. Present means do nothing, which keeps the GitHub path free of any package install; missing means fetch it, so the difference between the two runners is stated instead of hidden behind an unconditional apt-get. Also rewrites the reachability comment into one block. It had grown into two stacked halves whose first half still described the behaviour of the version before last - both reasons (the loop against a discovery 503, counting Ready nodes against an empty list that exits 0) now stand together with the evidence that the second one is what made the inotify failure visible at all.	2026-09-17 01:00:38 +02:00
jklein	417dff0f80	install-test: wait for a Ready node, not for an answer ... Second defect in the same check, and the more serious one: kubectl get nodes exits 0 on an EMPTY list. The cluster on Gitea answered while its node had not registered, the step logged 'No resources found' and went green, and the failure surfaced five minutes later as a pod stuck in Pending with no node and no scheduling event - the cause nowhere near the symptom. kubectl wait --for=condition=Ready nodes --all has the same hole; with zero nodes it succeeds vacuously. It now counts Ready nodes, and on timeout dumps the node conditions and the k3s server log so the error picture is in the job that caused it.	2026-09-17 00:46:54 +02:00
jklein	4766126618	install-test: poll for the cluster instead of asking once ... The reachability check added with the containerisation fix was itself racy and went red on one of two legs of the same GitHub run: k3d's --wait returns when the node container reports ready, but the API server can still answer discovery with 503 for a moment after that, and kubectl cluster-info asked exactly once. A check that produces sporadic red is worse than no check - that is the one property #227 rules out explicitly. It now polls kubectl get nodes, which is the thing that has to work and exercises discovery on the way.	2026-09-17 00:38:41 +02:00
jklein	31e4260580	install-test: reach the k3d cluster when the job itself is a container ... Closes the last gap from #227. k3d publishes the API server port on the Docker HOST. On GitHub's hosted runners the job is that host, so the https://0.0.0.0:<port> k3d writes into the kubeconfig works. Every Gitea Actions job is itself a container, and there the host is the dind container: 0.0.0.0 points at the job container, where nothing listens. The cluster comes up cleanly and the first kubectl call is refused - as measured, surfacing two steps later as a validation error on the fixtures, which named nothing useful. The case is decided on whether THIS job runs in a container, not on which forge it runs on. github.server_url would pick the right branch today and still be wrong: a self-hosted GitHub runner in a container has the identical problem, and a condition that says GitHub while meaning not-containerised is the kind of lie this repo exists to remove. The detection is the same question the fix needs answered anyway - ask the daemon about ourselves. In a container it returns our network, k3d joins it, and Docker's DNS resolves the node names; on a host it returns nothing and the previous path is taken unchanged. kubectl cluster-info and get nodes now run inside the create step, so a cluster that is up but unreachable fails where it is caused instead of two steps downstream.	2026-09-17 00:29:08 +02:00
jklein	301fc0d4e5	install-test: one cluster per matrix leg, and a pinned kubectl ... Two assumptions about the runner environment, both found by the Gitea probe of #225 and both wrong on GitHub as well - they simply could not show there. CLUSTER NAME. Every leg created a cluster called "install-test". On GitHub each matrix leg gets its own VM with its own Docker daemon, so two legs never saw each other and the fixed name looked fine for two years. Gitea runs all legs of a matrix CONCURRENTLY in ONE job on ONE daemon, and there it collides immediately: one leg logs "Re-using existing network 'k3d-install-test'", the other dies on "The container name /k3d-install-test-server-0 is already in use", and then the first leg's rollback deletes the shared network under the second. Two red legs, and neither message names the cause. The cluster is now named after the chart, in the create step and in the delete step - a blanket cleanup would tear down the neighbour's cluster, which was the half of the collision that turned one failure into two. ci/run-install-test.sh never touches k3d, so nothing else had to move. The bare chart name rather than a prefixed one, measured not assumed: k3d v5.9.0 accepts a cluster name of 32 characters and rejects 33 ("Cluster name must be <= 32 characters"), and the longest chart here is calibre-web-automated at 21. "install-test-<chart>" would be 34 - it would break that one chart and no other, which is worse than the fixed name because it only sometimes breaks. A guard states the limit instead of leaving it to be rediscovered. KUBECTL. It was inherited from the runner image. The Gitea image has none ("kubectl: command not found", 0 seconds into the chart install), but that is how it was noticed, not why it is being changed: a client version that arrives with the image drifts with every image rebuild, and an install-test should run against a known one. GitHub's image carrying one only makes the drift invisible there. Pinned to v1.35.5 to match the K3S_IMAGE it talks to, tracked by Renovate the same way TRIVY_VERSION is, and guarded against skew: kubectl supports one minor away from the server, Renovate moves KUBECTL_VERSION on its own, and K3S_IMAGE is tracked by nothing. Dry run proves both directions - the rule extracts (kubernetes/kubernetes, github-releases) and it fires (from v1.34.0 the lookup offers v1.37.0, minor). That same measurement shows the guard is not theoretical: Renovate jumps several minors in one PR, so it will go red on purpose, naming which pin to move.	2026-09-17 00:22:16 +02:00
jklein	b9917505cd	Drop the issue-migration script: a one-off job is not repo content ... The migration from GitHub issues to Gitea runs exactly once, by hand over the API. Checking a script in for it would leave permanently maintained code behind for a task that stops existing after its single run - and worse, it would read to every later visitor as a tool meant to be reused. A one-off move is carried out once and is history afterwards; it is not a part of the repository. The one reference in CLAUDE.md is rewritten rather than deleted: that the issue numbers do not survive the move is still true and still worth knowing, so the bullet now says a `#n` in this repo means the GitHub issue, and that what to do about the old references is open in #225.	2026-09-16 16:02:41 +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	241eda15a4	Merge pull request #252 from jk-cluster/renovate/gotenberg-gotenberg-8.x ... Update gotenberg/gotenberg Docker tag to v8.37.0	2026-09-16 13:45:10 +00:00
jklein	c1fddf1966	Merge pull request #254 from jk-cluster/renovate/docker.io-searxng-searxng-2026.x ... Update docker.io/searxng/searxng Docker tag to v2026.9.13-3b8009065	2026-09-16 13:45:02 +00:00
jlab-renovate[bot]	0f92701f4e	Update docker.io/searxng/searxng Docker tag to v2026.9.13-3b8009065	2026-09-16 13:00:56 +00: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
jlab-renovate[bot]	f9a5e48461	Update gotenberg/gotenberg Docker tag to v8.37.0	2026-09-14 15:02:17 +00:00