18 Commits

Include renames

Author	SHA1	Message	Date
jklein	28a0230ef0	feat!: NetworkPolicy in the NodePort and game-server charts, on by default ... garage, minecraft-router, minecraft-server, samba, teamspeak-server, satisfactory. One major each. These are the charts the plan said to leave for last, and they earned it - three of them changed the convention rather than just consuming it. GARAGE is the clearest illustration after keycloak. Its four ports split three ways: s3 and web are RESTRICTED by source (no probe touches them), admin is the probe path and stays open inside the cluster - which is uncomfortable, because admin is also the admin API, and that is said out loud instead of glossed - and rpc gets the narrowest rule the object can express, a podSelector with no namespaceSelector. All four numbers come from garage.settings. MINECRAFT-SERVER is the tightest policy in the repository, and the reason is worth knowing: all three of its probes are EXEC probes, which put no packet on the network, so no port has to stay open for the kubelet and no probeSources value is needed at all. RCON and metrics are restricted outright. The game port has two branches rendered from the same value the Service reads - server.service.type NodePort means players arrive from the internet and the rule must be open; anything else means the only path is in-cluster, so the rule is restricted and the router's namespace has to be in allowedNamespaces. MINECRAFT-ROUTER derives its egress from the routing table instead of guessing: server.backendPort plus the "port" override of every mapping that sets one. Add a backend on a non-standard port and the policy follows. What it cannot express is the destination - mappings name hosts, and this object matches no hostname - so the rule is wider than the routing table, and that is written down. SATISFACTORY gets policyTypes: [Ingress] and no egress section, and the second half of the reason is the deciding one. Steam's content delivery is not a pinnable port set (SteamCMD over TCP 80/443/27015-27050, master servers over UDP 27000-27100 and 4380, changed by Valve, re-downloaded on every update) - and this is the ONE chart with no install-test at all, because the image is multiple GB and the first start pulls over 10GB. An egress cap here would be the only one in the sweep with no empirical check behind it, on the chart whose correct port set is least knowable. SAMBA and TEAMSPEAK-SERVER carry the NodePort lesson explicitly: the rules name 445/139 and the pod's voice and file-transfer ports, never the NodePorts, and teamspeak's file is explicit that its pod port and NodePort happening to share a number is a coincidence of its values rather than a pattern to copy. Teamspeak's voice rule is UDP, and the file says why that matters: a TCP rule on the same number is accepted, looks complete, and drops every voice packet. THREE THINGS THE CHECKS CAUGHT WHILE THIS BATCH WAS WRITTEN, all of them real: - minecraft-server's RCON rule named a port the pod does not declare. The containerPort is gated on server.rcon.enabled and the rule was not, so assertion 2 rejected it. The rule now carries the same gate. - samba and satisfactory would have shipped allowedNamespaces and probeSources values that reach NO rule - every one of their inbound rules is open to any source. A value that silently does nothing is worse than one that is absent, because it reads as a control, so both are gone from those two charts and from their schemas, with the reason in values.yaml. teamspeak-server loses probeSources for the same reason and keeps allowedNamespaces, which its web-query rule uses. - the policy templates no longer declare template variables they do not use. samba keeps one, satisfactory none. Part of #5	2026-10-14 14:37:51 +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	9c0039685b	minecraft-server: an overridable image tag and a Java-line guard (5.0.0+up2026.8.2.java25) ... Only the newest Java line is maintained from now on. Publishing the chart once per line out of one directory is what made the lines drift apart (#158): a change reached whichever line happened to lie in the directory. java8 and java17 stay published as frozen artifacts at 4.0.0, java21 at 4.1.0, and none of them gets another chart change. Running an older JVM is now a decision at rollout time instead of a chart version: image.tagOverride replaces the tag that otherwise comes from appVersion. It is not called image.tag because it decouples the running image from the chart version, and it is deliberately outside Renovate's reach - renovate.json5 keeps tracking appVersion only. The pairing of tag and minecraft.version is now checked at render time and fails with both values named, the line each one belongs to, and where the tag came from. Until now nothing checked it: a mismatch installed silently and only the container failed afterwards. The boundaries are Mojang's, swept over all 102 releases of the piston-meta manifest (javaVersion.majorVersion): up to 1.16.5 Java 8, 1.17-1.17.1 Java 16, 1.18-1.20.4 Java 17, 1.20.5-1.21.11 Java 21, 26.1 and later Java 25. The 1.17 line was the one gap the chart's own notes did not cover. Two cases pass unchecked on purpose, documented in values.yaml and NOTES.txt: a tag without a recognizable java<N> part, and a minecraft.version that is not a plain numeric x[.y[.z]]. A guard that rejects what it does not understand gets worked around instead of respected. Major, because an installation that already runs a mismatched pair stops rendering. It does not run today either - it now fails earlier and visibly.	2026-09-02 13:56:25 +02:00
jklein	bfa72181eb	minecraft-server: move to the java25 line (4.1.0+up2026.8.2.java25) ... Minecraft 26.2 requires Java 25, so the chart's default minecraft.version can only be raised on a java25 image. appVersion becomes 2026.8.2-java25 - the same dated upstream release the java21 line ships, so the only variables that change are the JVM and the Minecraft version. The chart version stays at 4.1.0: the Java lines are siblings of one chart generation, not successors, and are told apart by the +up suffix. The Java boundaries in the values.yaml / NOTES.txt comments are read off Mojang's version manifest (javaVersion.majorVersion per release), not estimated: 1.21.11 is the last release asking for Java 21, every release from 26.1 on asks for Java 25.	2026-09-01 17:30:22 +02:00
jklein	8a68df737a	minecraft-server: restore the java21 line (4.0.1+up2026.8.2.java21) ... Closes the three-step round that carried the #99 null-safety to every Java line. Pure restoration of the directory to the newest line: version: 4.0.0+up2026.8.2.java17 -> 4.0.1+up2026.8.2.java21 appVersion: "2026.8.2-java17" -> "2026.8.2-java21" minecraft.version: "1.20.1" -> "1.21.1" Nothing changes in content, and that is not a claim but a measurement. Against the java21 state published from #156, the ENTIRE chart tree differs in exactly one line - the chart version - and .Chart.Version is not read by any template, so the rendering is byte-identical: 4.0.0+up2026.8.2.java21 (published) -> this chart: file tree: 1 differing line, Chart.yaml version rendering: byte-identical (CI values, serverpack init container enabled) main (java17) -> this chart: exactly TWO differences, both the line selection itself - image itzg/minecraft-server:2026.8.2-java17 -> :2026.8.2-java21 and env VERSION 1.20.1 -> 1.21.1. Why 4.0.1 and not 4.0.0: 4.0.0+up2026.8.2.java21 is already in the registry from #156, and helm push overwrites an existing OCI tag without complaint. The version check in validate-charts.yml does not catch this - it compares only against github.base_ref, where the version would read java17, so a republished 4.0.0 would pass the gate and silently overwrite the published artifact. Tracked as #160. What this round achieves, measured across the three published line states: templates/ and values.schema.json are byte-identical on java8 (f7047b8), java17 (2b22ce5) and java21 (this chart); values.yaml differs only in minecraft.version and the comment naming the appVersion; and all three now carry initImage alpine:3.24, so the bump that had reached only java21 is no longer missing on the other two. All three lines therefore run the same hardening, the same three exec probes, the same resources handling and the same null-safe fallbacks. Left untouched on purpose: the float64 quantity finding (#157) and seccompProfile (#161) - the latter has to be pulled through all three lines and has its own unknowns in gosu and the serverpack init container. Refs #99	2026-08-24 17:26:41 +02:00
jklein	73b304c1aa	minecraft-server: publish the java17 line (4.0.0+up2026.8.2.java17) ... Third of three line publications that carry the #99 null-safety to every Java line. Templates and schema are the same for all three lines; only the line-selecting fields change: version: 4.0.0+up2026.8.2.java8 -> 4.0.0+up2026.8.2.java17 appVersion: "2026.8.2-java8" -> "2026.8.2-java17" minecraft.version: "1.12.2" -> "1.20.1" (Java 17 runs Minecraft 1.18-1.20.4) What the diff does NOT show, same as for java8: the java17 line was last published as 3.0.0+up2026.8.2.java17, and since then main also moved the serverpack init image from alpine:3.22 to alpine:3.24 (commit 5a35ea4, which landed on the java21 line only). That bump rides along here. It is invisible in the diff against main, because relative to main the file already says 3.24 - the java8 publication in #159 brought it there. Relative to what a java17 release actually runs today it is a base-image change, so it is named here rather than left to be discovered. Measured against ci/minecraft-server/test-values.yaml with the serverpack init container enabled, compared structurally (documents paired by kind/name, recursive over keys) instead of line by line: 3.0.0+up2026.8.2.java17 (published) -> this chart: exactly ONE difference, initContainers[0].image alpine:3.22 -> alpine:3.24. main (java8) -> this chart: exactly TWO differences, both the line selection itself - image itzg/minecraft-server:2026.8.2-java8 -> :2026.8.2-java17 and env VERSION 1.12.2 -> 1.20.1. Hardening, the three exec probes, resources and the init.sh chown are unchanged, which is what the null-safety was built to do: it changes what an ERASED block renders, not what the defaults render. At file level the line invariant holds exactly - against main's tree the only differing files are Chart.yaml and values.yaml, in the three line fields plus the comment naming the appVersion. _helpers.tpl, values.schema.json and both templates are byte-identical across the lines. The null-safety itself is not re-swept - #156 proved it on identical templates. Confirmed once on this build that it carries: erasing both security contexts renders byte-identical to the defaults. Left untouched on purpose: the float64 quantity finding (#157), because multiplyQuantity is the same copy in all 21 charts and a single-chart fix would create drift, and seccompProfile (#84), which changes runtime behaviour and belongs in its own change. Refs #99	2026-08-24 17:19:50 +02:00
jklein	b049101da5	minecraft-server: publish the java8 line (4.0.0+up2026.8.2.java8) ... Second of three line publications that carry the #99 null-safety to every Java line. The chart is published once per line, the templates and the schema are the same for all three, and only the directory's line-selecting fields change: version: 4.0.0+up2026.8.2.java21 -> 4.0.0+up2026.8.2.java8 appVersion: "2026.8.2-java21" -> "2026.8.2-java8" minecraft.version: "1.21.1" -> "1.12.2" (Java 8 runs Minecraft <= 1.16.5) What the diff does NOT show, and what this commit therefore has to say out loud: the java8 line was last published as 3.0.0+up2026.8.2.java8, and since then main also moved the serverpack init image from alpine:3.22 to alpine:3.24 (commit 5a35ea4, which landed on the java21 line only). That bump rides along here. It is invisible in this PR's diff, because relative to main the file already says 3.24 - but relative to what a java8 release actually runs today it is a base-image change, and the cluster side has to know. Measured, rather than assumed. Rendered against ci/minecraft-server/test-values with the serverpack init container enabled and compared structurally (documents paired by kind/name, recursive over keys) instead of line by line: 3.0.0+up2026.8.2.java8 (published) -> this chart: exactly ONE difference, initContainers[0].image alpine:3.22 -> alpine:3.24. main (java21) -> this chart: exactly TWO differences, both the line selection itself - image itzg/minecraft-server:2026.8.2-java21 -> :2026.8.2-java8 and env VERSION 1.21.1 -> 1.12.2. Nothing else moves: the hardening, the three exec probes, the resources and the init.sh chown are unchanged, which is what the null-safety was built to do (it changes what an ERASED block renders, not what the defaults render). The null-safety itself is not re-swept here - #156 proved it on identical templates. Confirmed once on this build that it carries: erasing both security contexts renders byte-identical to the defaults. The float64 quantity finding (#157) is deliberately untouched, per its own issue: multiplyQuantity is the same copy in all 21 charts and a single-chart fix would create drift. Refs #99	2026-08-24 17:11:12 +02:00
jlab-renovate[bot]	5a35ea49b0	Update alpine Docker tag to v3.24	2026-08-24 10:16:01 +00:00
jklein	6543c6f02c	Update minecraft-server to the java21 line (3.0.0+up2026.8.2.java21) ... Last of the three publishes that carry the checksum annotations from 3.0.0+up2026.8.2.java8, leaving main on the line of the only running server. Same chart content as the java8 and java17 publishes, only the published Java line changes: appVersion moves to the dated tag 2026.8.2-java21 and the minecraft.version default moves to 1.21.1, the version ftb-skies-2 actually runs (Java 8 runs up to 1.16.5, 1.18-1.20.4 need Java 17, 1.20.5+ need Java 21). Against the state before this series (2.0.0+up2026.8.2.java21) the only replaced line in Chart.yaml and values.yaml is the chart version; appVersion and the minecraft.version default are byte-identical, everything else is additive. Refs #82.	2026-08-23 19:19:57 +02:00
jklein	d9f7b6553e	Update minecraft-server to the java17 line (3.0.0+up2026.8.2.java17) ... Second of the three publishes that carry the checksum annotations from 3.0.0+up2026.8.2.java8. Same chart content, only the published Java line changes: appVersion moves to the dated tag 2026.8.2-java17 and the minecraft.version default moves to 1.20.1, the line's matching Minecraft version (Java 8 runs up to 1.16.5, 1.18-1.20.4 need Java 17, 1.20.5+ need Java 21). Refs #82.	2026-08-23 19:15:18 +02:00
jklein	58ea3b62d4	Restart the server when its config changes (3.0.0+up2026.8.2.java8) ... The StatefulSet now carries two annotations over its two configuration sources, so a change to either produces a new pod template and a controlled restart: checksum/config the rendered ConfigMap (init.sh) - complete, Helm sees the whole content checksum/secret-ref the rendered OnePasswordItem - the op:// item path only, because the Secret's content is materialized by the operator and is unknown to Helm at render time Two separate annotations rather than one combined hash: they carry different guarantees, and a single number would blur "covers everything" and "covers the path but not the content" into one value that nobody can interpret in a kubectl describe. The operator's own operator.1password.io/auto-restart is deliberately NOT set: it restarts Deployments only. Verified in the operator source (main, 9c3b1b9): restartWorkloadsWithUpdatedSecrets lists nothing but appsv1.DeploymentList and getPodTemplate has a single case for *appsv1.Deployment. On this StatefulSet the annotation would be inert while suggesting the opposite, so the remaining gap - a rotated value inside the vault item - is documented in values.yaml instead. First of the three stage-3-style publishes, so the java8 line goes first and main ends up on java21. Only the published Java line differs between them: appVersion 2026.8.2-java8 and the matching minecraft.version default 1.12.2. Major bump: runtime behaviour changes. A configuration change now costs a full server restart - 124 s measured for ftb-skies on Longhorn. Refs #82.	2026-08-23 19:04:03 +02:00
jklein	751bed7b05	Update minecraft-server to the java21 line (2.0.0+up2026.8.2.java21) ... Last of the three stage-3 publishes, leaving main on the line of the only running server. Same chart content as 2.0.0+up2026.8.2.java8 and .java17, only the published Java line changes: appVersion moves to the dated tag 2026.8.2-java21 and the minecraft.version default moves to 1.21.1, the version ftb-skies-2 actually runs (Java 8 runs up to 1.16.5, 1.18-1.20.4 need Java 17, 1.20.5+ need Java 21).	2026-08-23 18:23:12 +02:00
jklein	0b3ea7728a	Update minecraft-server to the java17 line (2.0.0+up2026.8.2.java17) ... Second of the three stage-3 publishes. Same chart content as 2.0.0+up2026.8.2.java8, only the published Java line changes: appVersion moves to the dated tag 2026.8.2-java17 and the minecraft.version default moves to 1.20.1, which is the line's matching Minecraft version (Java 8 runs up to 1.16.5, 1.18-1.20.4 need Java 17, 1.20.5+ need Java 21).	2026-08-23 18:14:52 +02:00
jklein	4874e5db1f	Pin minecraft-server to dated image tags and fix the whitelist switch (2.0.0+up2026.8.2.java8) ... Stage 3 of the Fleet migration. Two changes, both breaking, hence the major bump from 1.0.0 to 2.0.0. Dated image tags: appVersion moves from the rolling line tag "java8" to the immutable upstream release tag "2026.8.2-java8". The rolling tags are rebuilt continuously, so a pod restart could pull a different image than the previous start without that being recorded anywhere. 2026.8.2 is the newest upstream release (published 2026-08-23) and exists for all three Java lines. Whitelist semantics: the chart now wires ENABLE_WHITELIST (and ENFORCE_WHITELIST) in both positions, so minecraft.whitelist.enabled: false actually switches the whitelist off. Previously the chart only emitted whitelist variables while enabled was true and had no way to express "off" - and because server.properties lives on the PVC, a release that had once written white-list=true kept it forever. players stays guarded by enabled, since a non-empty WHITELIST enables the whitelist in the image regardless of ENABLE_WHITELIST. The default flips from enabled: true to enabled: false. Under the corrected semantics the old default (enabled with an empty player list) would mean a server nobody can join; false matches both the image and vanilla Minecraft.	2026-08-23 18:06:23 +02:00
jklein	fd5692cac7	Update minecraft-server to the java21 line (1.0.0+upjava21) ... PR C of three, and the last of the stage-2 sequence. Same chart as 1.0.0+upjava8 and 1.0.0+upjava17, published for the third Java line, so main comes to rest on the line of the only server that is actually running. minecraft.version moves with it (1.20.1 -> 1.21.1): a Minecraft version only runs on a matching JVM, and 1.20.5+ needs Java 21. This default now equals what ftb-skies-2 sets in its own values file, so the install-test boots the production version rather than an arbitrary Java-21-capable one. The CI values deliberately do not override minecraft.version, so this default is what the install-test exercises.	2026-08-23 16:57:43 +02:00
jklein	766058258a	Update minecraft-server to the java17 line (1.0.0+upjava17) ... PR B of three. Same chart as 1.0.0+upjava8, published for the second Java line: appVersion selects the image tag, so the JVM is fixed per published chart version. minecraft.version moves with it (1.12.2 -> 1.20.1), because a Minecraft version only runs on a matching JVM: Java 8 goes up to 1.16.5, 1.18-1.20.4 need Java 17. Since 1.0.0 this default is no longer overridden in the CI values, so the install-test boots exactly this version and a mismatched default would fail CI instead of passing on a CI-only override.	2026-08-23 16:51:53 +02:00
jklein	227bcebeb6	Bring minecraft-server up to the chart style guidelines (1.0.0+upjava8) ... Stage 2 of the Fleet migration for minecraft-server. Major bump: runtime behaviour changes (probes, hardening) and the values interface breaks (resource renames, strict schema). Two real bugs first: - The container declared port 35565 while the Service targeted 25565. It only worked because targetPort was numeric. Both are now server.port (25565) and the Service targets the named port. - The download-serverpack init container was guarded by the map .Values.curseforgeServerpack instead of .enabled, so it rendered for every release and silently no-opped on an empty wget URL. Conventions: - Resources renamed to <release>-<chart>-<kind>, templates to <app>.<kind>.yaml. The PVC deliberately keeps its historical name - renaming it would provision a new, empty volume and orphan the worlds. - Probes (liveness/readiness/startup) via the image's own mc-health, so Ready means the server answers a server-list ping. Startup budget 20 min. - Hardened, values-configurable security contexts: non-root uid 1000, read-only root filesystem with an emptyDir at /tmp, all caps dropped. - Resources from values with the limitFactor helper; an unset memory request is derived from the JVM heap so the two cannot drift apart. - Additive env block rendered through tpl, pinned init image, storage class as a value, RCON wiring only when actually enabled. - curseforge/ftb/curseforgeServerpack are now mutually exclusive. - minecraft.version is pinned to the Java line instead of LATEST. - The mc-router auto-discovery annotation is gone; the service type it implicitly switched is now the explicit value server.service.type. Schema pilot (#68): values.schema.json with additionalProperties false on every chart-owned level, rejecting all three known dead keys.	2026-08-23 16:40:44 +02:00
jklein	a68192e5fb	Import minecraft-server chart for Fleet migration stage 1 (java8 line) ... Imports the chart from cluster-config functionally unchanged, wires it into the publish/validate/install-test pipelines and publishes it as the first of three Java lines (0.4.0+upjava8). The only deviation from the source chart is the chart-global scaleDown flag plus a server.replicas value, following the satisfactory pattern: two of the three servers stand at 0 replicas in the cluster, which the chart could not express, and Fleet would otherwise start them on reconcile. The default (scaleDown: false) still renders replicas: 1, so the rendering of the running server is unchanged - verified byte-identical against the three real values files for all three Java lines. Known deficiencies (hardening, probes, naming scheme, hardcoded values, missing icon, the misleading mc-router auto-discovery annotations) are left untouched on purpose and are scheduled for stage 2.	2026-08-23 15:57:17 +02:00