From b049101da585da917d7143e8a818425370856d6c Mon Sep 17 00:00:00 2001 From: jklein Date: Mon, 24 Aug 2026 17:11:12 +0200 Subject: [PATCH] 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 --- minecraft-server/Chart.yaml | 4 ++-- minecraft-server/values.yaml | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/minecraft-server/Chart.yaml b/minecraft-server/Chart.yaml index 381aec4..e4ed3d9 100644 --- a/minecraft-server/Chart.yaml +++ b/minecraft-server/Chart.yaml @@ -13,8 +13,8 @@ type: application # continuously, so a pod restart could pull a different image than the last one # without anything being recorded anywhere. The dated tags are immutable, so the # image is now pinned by the chart version like every other chart in this repo. -version: 4.0.0+up2026.8.2.java21 -appVersion: "2026.8.2-java21" +version: 4.0.0+up2026.8.2.java8 +appVersion: "2026.8.2-java8" maintainers: - name: jklein diff --git a/minecraft-server/values.yaml b/minecraft-server/values.yaml index 73d014c..dd6b73f 100644 --- a/minecraft-server/values.yaml +++ b/minecraft-server/values.yaml @@ -226,8 +226,8 @@ minecraft: # This value must match the Java line of the chart version: the image tag # comes from .Chart.AppVersion, so the JVM is fixed per published chart # version. Java 8 runs Minecraft up to 1.16.5, 1.18-1.20.4 need Java 17 and - # 1.20.5+ need Java 21. This chart publishes appVersion "2026.8.2-java21". - version: "1.21.1" + # 1.20.5+ need Java 21. This chart publishes appVersion "2026.8.2-java8". + version: "1.12.2" # curseforge, ftb and curseforgeServerpack are mutually exclusive - enabling # more than one is rejected by the chart (before 1.0.0 it silently rendered a