2 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	227bcebeb6	Bring minecraft-server up to the chart style guidelines (1.0.0+upjava8) ... Stage 2 of the Fleet migration for minecraft-server. Major bump: runtime behaviour changes (probes, hardening) and the values interface breaks (resource renames, strict schema). Two real bugs first: - The container declared port 35565 while the Service targeted 25565. It only worked because targetPort was numeric. Both are now server.port (25565) and the Service targets the named port. - The download-serverpack init container was guarded by the map .Values.curseforgeServerpack instead of .enabled, so it rendered for every release and silently no-opped on an empty wget URL. Conventions: - Resources renamed to <release>-<chart>-<kind>, templates to <app>.<kind>.yaml. The PVC deliberately keeps its historical name - renaming it would provision a new, empty volume and orphan the worlds. - Probes (liveness/readiness/startup) via the image's own mc-health, so Ready means the server answers a server-list ping. Startup budget 20 min. - Hardened, values-configurable security contexts: non-root uid 1000, read-only root filesystem with an emptyDir at /tmp, all caps dropped. - Resources from values with the limitFactor helper; an unset memory request is derived from the JVM heap so the two cannot drift apart. - Additive env block rendered through tpl, pinned init image, storage class as a value, RCON wiring only when actually enabled. - curseforge/ftb/curseforgeServerpack are now mutually exclusive. - minecraft.version is pinned to the Java line instead of LATEST. - The mc-router auto-discovery annotation is gone; the service type it implicitly switched is now the explicit value server.service.type. Schema pilot (#68): values.schema.json with additionalProperties false on every chart-owned level, rejecting all three known dead keys.	2026-08-23 16:40:44 +02:00