Files
helm-charts/ci/minecraft-server/test-values.yaml
T
jklein 198058b8bb Update minecraft-server to the java21 line (0.4.0+upjava21)
Last of the three Java-line publishes; main comes to rest on java21, the line
of the only running server, and the registry holds all three tags.

Only the two version lines in Chart.yaml change. Because the source chart in
cluster-config is itself on java21, this final state renders byte-identical to
it for mc-ftb-skies-2 with its real values file - the published end state is
exactly what cluster-config runs today.

The CI install values move along with the appVersion, as in the java17 PR:
the JVM is fixed per published chart version and no single Minecraft version
boots on all three lines. Since the chart has no probes, a version the JVM
cannot load would crash after the rollout returned and still leave a green
install-test behind. minecraft.version therefore moves 1.20.1 -> 1.21.1, which
is also what ftb-skies-2 sets in its real values file, so CI exercises the
production version. ci/ is outside the chart directory and is neither packaged
nor published.
2026-08-23 16:12:15 +02:00

41 lines
2.1 KiB
YAML

# Values for the minecraft-server install-test. Kept as close to the real
# deployments as possible; only what a CI runner cannot provide is overridden.
#
# 1. minecraft.version: the image tag comes from .Chart.AppVersion, so the JVM
# in the image is fixed per published chart version and the Minecraft
# version has to match that Java line - Java 8 runs Minecraft only up to
# 1.16.5, 1.18-1.20.4 need Java 17, and 1.20.5+ need Java 21. No single
# Minecraft version boots on all three lines, so this value is bumped
# together with appVersion in every Java-line PR.
# This chart version publishes appVersion "java21", hence 1.21.1 - which is
# also what ftb-skies-2, the one server actually running on this line, sets
# in its real values file, so CI exercises the production version rather
# than an arbitrary Java-21-capable one.
# The production default is "LATEST", which would drift on every restart.
# 2. minecraft.resources.storage: the production 32Gi world volume is backed by
# a static hostPath PV in CI (see fixtures.yaml); 2Gi is plenty for a server
# that only has to boot.
# 3. minecraft.resources.memory: sets the JVM heap (-Xmx); 1G instead of 4G
# keeps the runner comfortable. The container resource *requests* are
# hardcoded in the template (cpu 2 / memory 4Gi) and cannot be overridden -
# they fit a 4-vCPU/16GB GitHub runner, and making them configurable is part
# of the stage-2 convention alignment.
# 4. server.outwardPort stays at the chart default 30565: unlike minecraft-router
# that default is already inside the Kubernetes node-port range
# (30000-32767), so the k3d API server accepts it unchanged.
secrets:
minecraftServerRef: vaults/CI/items/minecraft-server
minecraft:
version: "1.21.1"
management:
# opPlayers deliberately stays at the default (null): the image resolves
# every name in OPS against the external Playerdb API and aborts the whole
# startup when a name does not resolve, so any placeholder name would break
# the install-test and a real name would make CI depend on a third-party
# lookup.
maxPlayers: 2
resources:
storage: 2Gi
memory: "1"