jklein
bfa72181eb
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.
43 lines
2.1 KiB
YAML
43 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.
|
|
#
|
|
# minecraft.version is deliberately NOT set here any more. Since chart 1.0.0 the
|
|
# chart ships a pinned default that belongs to the Java line it publishes (the
|
|
# image tag comes from .Chart.AppVersion, and Java 8 runs Minecraft only up to
|
|
# 1.16.5, 1.18-1.20.4 need Java 17, 1.20.5-1.21.11 need Java 21 and 26.1+ needs
|
|
# Java 25). Leaving it unset means the install-test exercises exactly the
|
|
# default a user would get, so a Java line published with a mismatched default
|
|
# version fails CI instead of passing on a CI-only override.
|
|
#
|
|
# server.service.type is not set either: the default is ClusterIP, which is what
|
|
# all three real deployments run (routing is done by the static mappings of the
|
|
# minecraft-router chart). That also keeps CI free of node-port allocation.
|
|
secrets:
|
|
minecraftServerRef: vaults/CI/items/minecraft-server
|
|
|
|
minecraft:
|
|
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:
|
|
# 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.
|
|
storage: 2Gi
|
|
# JVM heap. 1G instead of 4G keeps the runner comfortable - and since chart
|
|
# 1.0.0 this also drives the container's memory request (1Gi) and, via
|
|
# limitFactor 3, its limit (3Gi), so the runner is not asked for the
|
|
# production-sized 4Gi/12Gi any more.
|
|
memory: "1"
|
|
|
|
server:
|
|
resources:
|
|
requests:
|
|
# The production default is 2 CPUs, which would not leave much room on a
|
|
# 4-vCPU GitHub runner alongside the k3d control plane. Since chart 1.0.0
|
|
# this is configurable instead of hardcoded in the template.
|
|
cpu: "500m"
|