Teil von #157 and Teil von #43, in one change because both are additive and neither moves a rendered object. #157 - multiplyQuantity turned large numbers into exponential notation. The null-safe fallback helpers pass values through fromYaml, which parses every number as float64, and Go's "%v" switches float64 to exponential notation from about 1e6 upwards. A bare byte count like 1048576 became "1.048576e+06". The chart has two affected positions, and they fail differently: - the entry of multiplyQuantity aborts the render loudly, because the exponent is caught by the suffix check (unsupported resource quantity suffix "e+06"). - the output of a non-integer product never reaches that check and renders silently: a fractional limitFactor together with a bare number produced "1.4999985e+06" in the manifest, rejected only later by the API server. Note that this chart's schema types limitFactor as "number" with exclusiveMinimum 0, not as an integer, so the silent path is reachable here through ordinary values. Both positions now go through a new minecraft-server.formatNumber helper, the canonical correction already applied to template-chart, voucher-vault, zipline, outline and minecraft-router. #43 - NOTES.txt for this chart. It prints what an operator would otherwise have to read out of the templates, conditional on the values actually set: - access, which is not a URL: ClusterIP means the server is reachable only once its Service name is entered in the minecraft-router release's static mappings, since that router does no auto-discovery; NodePort prints the node port and warns when it falls outside 30000-32767. - the Java line, derived from appVersion rather than written into the file, so it holds for all three published lines, together with the fact that nothing checks minecraft.version against it. - what a green rollout does not prove. The probes do run a real server-list ping, so Ready means the server answers - but a ping is answered before any login, so every login-side refusal is invisible to all three probes. The whitelist is the practical case: enabled without players locks everyone out while the rollout stays green. - which fields the 1Password item must carry, listed only for the features actually enabled, plus the documented gap that a changed item content does not roll the pod. - the world PVC that helm uninstall deletes, the two memory numbers and how they decouple, RCON not being published by the Service, the declared but unserved metrics port, and the enabled modpack source. No real domain anywhere; the router example uses mc.example.com. Verified: helm lint --strict clean on all three Java lines; rendering the CI values and the chart defaults is byte-identical to origin/main, so no Kubernetes object changes and the minor bump is the right one.
21 lines
896 B
YAML
21 lines
896 B
YAML
apiVersion: v2
|
|
name: minecraft-server
|
|
description: A Helm chart for deploying a itzg/minecraft-server
|
|
icon: https://avatars.githubusercontent.com/u/988985
|
|
|
|
type: application
|
|
|
|
# The Java line of this chart version is chosen through appVersion, which is
|
|
# the image tag: the chart is published once per line (java8 / java17 / java21)
|
|
# and minecraft.version in values.yaml must match the line published here.
|
|
# Since chart 2.0.0 the tag is a DATED upstream release ("<release>-java<N>")
|
|
# instead of the rolling line tag ("java<N>"): the rolling tags are rebuilt
|
|
# 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.1.0+up2026.8.2.java21
|
|
appVersion: "2026.8.2-java21"
|
|
|
|
maintainers:
|
|
- name: jklein
|