fix(ontoserver): stop config passthroughs re-enabling writes on scaled deployments

[edeati]

Follow-up to #15. Removing allowScaledReadWrite closed one route to the unsupported scaled read-write topology; this closes the other.

The gap

Scaled deployments are read-only, and the chart declares that to the server. But ontoserver.config and ontoserver.secretConfig render after the chart's own entries in the container's env list (deployment.yaml:220), Kubernetes does not reject duplicate env names, and the later entry is the one that applies.

So a values file could set type: scaled with isReadOnly: true, pass the render-time guard, and still end up with a scaled server that accepts writes — the passthrough quietly winning over the chart.

The guard

Validation now rejects any such entry in either passthrough. Matching is normalised — lowercased, with _ and - folded to . — so every form Spring will resolve a property from is caught, including the older spelling that still applies on pre-2023 images and the uppercase underscored environment form.

existingSecretConfig and externalSecret are deliberately not checked, and the template says why: their contents are opaque at render time, and they arrive via envFrom, which Kubernetes applies before the container's own env — so the chart's entry still wins on that path and there is nothing to guard.

Nothing about what the chart sends to the server changes. The guard is only what stops it being shadowed.

Verification

• helm lint clean; helm unittest 276 pass (5 new)
• New tests cover every accepted spelling, both ontoserver.config and ontoserver.secretConfig, and a negative case proving an unrelated passthrough entry (ontoserver.fhir.closureTable.max) still renders — an over-broad match would otherwise break legitimate config
• No README parameter-table drift — no values were added

Cuts 0.5.2 as a fix:.

🤖 Generated with Claude Code