4 Commits

Include renames

Author	SHA1	Message	Date
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	5c5160a920	minecraft-server: NOTES.txt and the exponential-quantity fix (4.1.0+up2026.8.2.java21) ... 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.	2026-08-29 00:43:22 +02:00