7 Commits

Include renames

Author	SHA1	Message	Date
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	c6583468c7	minecraft-router: NOTES.txt and exponential-notation fix (4.1.0+up1.46.4) ... Teil von #157: multiplyQuantity turned every number from the null-safe fallback helpers into a float64 via fromYaml, and Go's "%v" switches float64 to exponential notation from about 1e6 upwards. A bare byte count like 1048576 became "1.048576e+06": the integer path aborted the render on the suffix check, while the non-integer path (a fractional limitFactor) rendered the invalid quantity silently and only failed at the API server. Both string conversions now go through the canonical formatNumber helper, identical to the fix already merged for template-chart, voucher-vault and zipline. Teil von #43: adds a NOTES.txt. minecraft-router has no Ingress and no URL, so the notes name the actual way in - the NodePort Service and the fact that the routing decision is made on the hostname from the Minecraft handshake - print the effective routing table, and state the traps: the nodePort outside the default range, mappings as the only source of routes (no Kubernetes auto-discovery in this chart), the restart a routing change costs, that a Ready router says nothing about any backend, and that API writes do not survive a restart. Conditional blocks for the out-of-range nodePort, scale-to-zero, more than one replica and server.env. No production domain anywhere; examples use example.com and cluster-internal names. Minor bump, appVersion unchanged.	2026-08-29 00:32:25 +02:00
jklein	6c73ef874b	Eight charts: seccompProfile RuntimeDefault and qualified images ... Sets seccompProfile.type: RuntimeDefault in the pod security context of minecraft-router, outline, urlaubsverwaltung, zipline, voucher-vault, satisfactory, patchmon and calibre-web-automated, so the container runtime's default syscall filter applies to every container in the pod. The value lives in the pod context rather than the container context because it covers init containers and any container added later without being repeated; a container that needs a different filter can still override it under securityContext.container, which wins over the pod value. Five of the eight also get the docker.io/ prefix on their previously unqualified image references, so the pull no longer depends on the runtime's default-registry setting: itzg/mc-router, outlinewiki/outline, urlaubsverwaltung/urlaubsverwaltung, l4rm4nd/vouchervault (twice, app and init container) and guacamole/guacd:1.6.0. zipline, satisfactory and calibre-web-automated were already qualified with ghcr.io. Verified in a throwaway k3d cluster against real application work, not just a Running pod, and with Seccomp: 2 (filter mode) read from /proc/<pid>/status inside each container: - minecraft-router: a Minecraft handshake for a mapped domain travels through the router to a backend and the backend's status payload comes back to the client. - outline: all migrations apply (45 tables), OIDC discovery succeeds and the server-rendered page answers 200 with <title>Outline</title>. - urlaubsverwaltung: Liquibase applies 79 changesets (35 tables), the app seeds its settings and vacation types, /login answers 200. - zipline: 27 migrations applied, then a full round trip - first user created, login, token, upload, and the file downloaded back byte-exact from the PVC. - voucher-vault: the init container's collectstatic output is served (200, 22 KB), Django has its 22 tables and uWSGI answers 200 with <title>VoucherVault</title>. - satisfactory: application behavior is NOT proven - the image is multiple GB and pulls 10 GB+ of game files on first start, which is why the chart sits in ci/excluded-charts.txt. What is proven is that the rendered pod securityContext is accepted server-side and yields Seccomp: 2 with uid/gid 1000 on a substitute image. - patchmon: both containers run under the pod profile and both report Seccomp: 2. The server applies 47 migrations (44 tables), connects to Postgres and Redis and serves its dashboard; guacd answers a real Guacamole "select rdp" instruction with its full args list, over the same 127.0.0.1:4822 path the chart wires up. - calibre-web-automated: the readOnlyRootFilesystem: false deviation is unaffected - id abc is still uid 1000 (not the 911 the image falls back to in read-only mode), /config and the Calibre metadata.db are owned by 1000, and both the root s6 init and the uid-1000 application report Seccomp: 2. calibredb 9.1 runs and adds a book. Its IPC worker prints a traceback while doing so, but an unconfined control pod on the same image prints the same class of traceback, so it is not the filter. trivy config now reports "0 to act on" for all eight; the untouched samba still shows KSV-0104 and KSV-0030, which confirms these charts are what closed the findings. No values.schema.json needed changing: in all eight schemas securityContext.pod is type ["object", "null"] with no property restrictions, so the new key validates as it stands. The #99 null paths still hold - nulling securityContext or securityContext.pod falls back to the defaults including the new one. Renovate resolves the prefixed guacd reference: a local dry-run lookup (renovate 44.40.1, --platform=local --dry-run=lookup) reports depName docker.io/guacamole/guacd against registryUrl https://index.docker.io with lookupName guacamole/guacd, currentVersion 1.6.0 and its real release timestamp, with no warnings. The other four prefixed references live in templates, which Renovate never reads - they are tracked by the customManagers via appVersion in Chart.yaml with a depName hardcoded in renovate.json5, so they are unaffected. Major bump for all eight: runtime behavior changes. Refs #84	2026-08-24 13:17:14 +02:00
jklein	a76accf7ad	minecraft-router: strict values.schema.json and null-safe hardening ... No ingress gate: this chart has no Ingress at all (clients reach it via a NodePort), and ingress.domain appears neither in its templates nor in its values. 1. values.schema.json (#68): additionalProperties: false on every chart-owned object level, including the entries of the mappings list, where domain and internalUrl are required. 2. Null-safety for hardening, probes and resources (#99). Two things a rebuilt default probe must not lose, both verified: - the API port is addressed by NAME ("api-port"), so the probe keeps working when server.apiPort is overridden. - mc-router still has no /health endpoint in 1.46.4, so GET /routes is the health signal, and the "Accept: application/json" header belongs to that request. The pod context keeps pinning uid/gid 10000 even though the image declares USER 65532 since 1.46.0, so the runtime identity does not silently change with the base image. mappings stays deliberately not null-safe: the chart fails loudly on a missing or empty routing table, which is the loud class #99 excludes - a router without routes is not operable and has no sensible default. Rendering with normal values is byte-identical to 2.0.0.	2026-08-23 21:49:18 +02:00
jklein	e4b3c06674	Restart the router when its routing config changes (2.0.0+up1.46.4) ... The deployment now carries a checksum/config annotation over the rendered ConfigMap, so a changed routing table produces a new pod template and a controlled rollout. Without it a mapping change was inert but looked successful: the file is mounted with subPath (kubelet never refreshes those in a running container) and mc-router reads ROUTES_CONFIG only at startup. That combination caused the minecraft-server stage-3 outage - the ConfigMap pointed at the renamed services, the running router kept proxying to the old ones, and the pod stayed Ready throughout. Major bump: runtime behaviour changes. A mapping change now costs a router restart (~4.5 s in k3d, so roughly 17-19 s in the real cluster) during which clients cannot connect. That restart is what makes the change take effect at all. Refs #82.	2026-08-23 18:52:19 +02:00
jklein	c20ad389f2	Minecraft-router chart: naming scheme, hardening, probes, values interface ... Stage 2 of the Fleet migration for minecraft-router: bring the chart up to the repo style guidelines. Chart 0.1.1+up1.25.1 -> 1.0.0+up1.25.1 (major: resource renames, mappings becomes required, probes and security hardening change the runtime behavior; appVersion unchanged). - Resources renamed to {{ .Release.Name }}-{{ .Chart.Name }}-<kind>, templates to <chart>.<kind>.yaml; the deployment label now matches its own selector. - mappings is required and must not be empty (the old default rendered "<nil>": "<nil>:25565"); every entry needs domain and internalUrl. - Ports come from values: server.port (router listen port, also passed as --port), server.backendPort (default backend port, overridable per mapping), server.apiPort (--api-binding, used by the probes). Defaults stay 25565 / 25565 / 8080, server.outwardPort keeps its 25565 default and comment. - _helpers.tpl added (resources/limitFactor and replicas/scaleDown helpers), resources come from values, no CPU limit. - replicas value plus the chart-global scaleDown flag. - Additive env block rendered through tpl (value / secretKeyRef / configMapKeyRef). - Values-configurable securityContext.pod / .container with hardened defaults: non-root uid/gid 10000, readOnlyRootFilesystem, no privilege escalation, all capabilities dropped. - Liveness, readiness and startup probes on the mc-router API: GET /routes with an "Accept: application/json" header (the API router matches on that header and answers 404 without it). - icon added to Chart.yaml. - CI fixture supplies mappings; README chart table entry updated.	2026-08-23 15:14:49 +02:00
jklein	3be5111630	Import minecraft-router chart unchanged (Fleet migration stage 1) ... Takes the existing mc-router chart over from cluster-config as-is so the deployment can move to Fleet without any change to the rolled-out state. Convention alignment follows in stage 2, the app update in stage 3. The only deviation from "unchanged": Chart.yaml carried name: minecraft-server (copy-paste from the sister chart). The publish job pushes by the glob <directory>-*.tgz while helm package names the archive after the Chart.yaml name, so without this correction the push finds no file. Version 0.1.1+up1.25.1 - chart semver stays at 0.1.1, the +up suffix is repo policy and does not affect rendering. Also wires up CI: publish workflow, change-app-version choice list, install-test values (CI-only node-port override, since 25565 is outside the k3d default range) and the README chart table.	2026-08-23 12:58:21 +02:00