3 Commits

Include renames

Author	SHA1	Message	Date
jklein	57e54f93fc	satisfactory: dev and server fall back instead of aborting (7.0.1) ... --set dev=null aborted the render at .Values.dev.debug and --set server=null at .Values.server.replicas, while the third block, game, has fallen back to the chart defaults since 7.0.0. Half-safe is the worse state of the two: whoever sees game=null work assumes server=null does too. Both blocks now run through satisfactory.defaultedDict like game, via two new helpers next to it. server.resources is deliberately NOT re-defaulted there - it already runs through satisfactory.effectiveResources, which carries those defaults and is null-safe on its own, and a second copy of limitFactor: 2 / 4Gi / 1 / 5Gi would be a third place for them to drift. server is read in four files, not one, and the fourth is NOTES.txt, which helm template never renders - a fix confined to the manifests would have looked green and still aborted on a real helm install. All four go through the helpers. The single erased key was the quieter half of the bug and is fixed with it: a nulled server.gamePort rendered "port:" and "nodePort:" empty into the Service and an empty containerPort into the StatefulSet, and a nulled server.storage a PVC asking for no size - manifests rejected by nothing until the API server saw them. server.storage was documented in values.schema.json as deliberately not null-safe; that reasoning does not survive the block-level case, because it made "server: null" render a sizeless PVC instead of falling back like everything else. The schema note is replaced rather than left lying. Rendered output for valid values is unchanged: helm template against the chart defaults and against a full override set is byte-identical to 7.0.0, and so is NOTES.txt. Hence a patch bump, appVersion untouched. Fixes #16	2026-09-22 19:59:35 +00:00
jklein	485f4fa52b	satisfactory: game.enableSeasonalEvents says what it does (7.0.0+upv1.9.10) ... game.seasonalEvents was handed to the container unchanged, into the image's DISABLESEASONALEVENTS. Its default true therefore wrote DISABLESEASONALEVENTS=true: the seasonal events were OFF in every install this chart has ever produced, while values.schema.json described the very same key as "true means events are enabled" (#215). Of the two ways out, this is the loud one. Inverting the template under the old key would have flipped the behaviour of every existing release in silence - the same class of mistake that created the issue. Renaming the key cannot be missed: game.seasonalEvents no longer exists, additionalProperties is false on the game block, and a values file that still carries it fails schema validation on upgrade instead of quietly meaning the opposite. The new key is positive (enableSeasonalEvents) to avoid a double negative, so the chart negates it on the way into the env var. Go's "not" cannot do that: it reads every non-empty string as true, and the schema deliberately accepts the string form of booleans, so "false" would have flipped the wrong way. The helper compares explicitly and fails on anything that is neither true nor false rather than filing it under "off". The default is enableSeasonalEvents: false, which renders the DISABLESEASONALEVENTS this chart has always rendered. At chart defaults the 6.1.0 and 7.0.0 manifests are identical, so upgrading alone moves no server; switching the events on is now a deliberate act with a key that means it. Separate finding from the same issue, fixed here because it lives in the block being touched: "--set game=null" - or a leftover "game:" whose sub-keys were deleted - aborted the render with a nil pointer at .Values.game.maxPlayers. The game block never got the null-safe treatment of #99 that probes, security contexts and resources have. It now falls back to the documented defaults, and the schema accepts the null accordingly. The same gap remains in the dev and server blocks; it is reported, not fixed here. Major bump: a values key is removed, and the schema rejects it.	2026-09-02 13:42:39 +02:00
jklein	290c69cc7d	satisfactory: strict values.schema.json and null-safe hardening ... No ingress gate: this chart has no Ingress at all (game and messaging ports are exposed via NodePort), and ingress.domain appears neither in its templates nor in its values. 1. values.schema.json (#68): additionalProperties: false on every chart-owned object level. Like teamspeak-server, this chart keeps env, probes and securityContext at the TOP level, and the schema mirrors that shape. 2. Null-safety for hardening, probes and resources (#99). What a rebuilt default must not lose here: - liveness and startup run the image's own healthcheck script via exec. It queries the server's HTTPS API on SERVERGAMEPORT, so it survives a port override, which a tcpSocket default could not. - readiness keeps the named "api" port. - the resources default keeps limitFactor 2 rather than the repo-wide 3, which is what holds the memory limit at the published 8Gi. - the pod context keeps fsGroupChangePolicy OnRootMismatch, which is what avoids a recursive chown of multi-GB game files on every start. server.storage stays deliberately not null-safe: an erased value yields an invalid PVC, which is the loud class #99 excludes. This chart is excluded from the CI install-test, so the local proof is the only one. Rendering is byte-identical to 4.0.0 with default values and with the production bundle values, and the rendered manifests were additionally validated by the cluster's API server via a server-side dry-run.	2026-08-23 21:28:52 +02:00