# Overlay for ci/run-selector-match-test.sh, applied ON TOP of # ci/stalwart/test-values.yaml and nowhere else - not by the install-test, not by # the Trivy scan, not by the quantity render test. # # WHY IT EXISTS. Both objects this test looks at are rendered only while a node # group's COMPUTED replica count is >= 2, and the install-test fixture runs # full: 1 / mx: 0 deliberately (a second pod would need a real in-memory store, # and a running "mx" pod would fail-open into a second full node against an # empty database). So without this file stalwart renders no PodDisruptionBudget # and no topologySpreadConstraints, and the test would be green for the chart it # was written for, having looked at nothing. ci/run-selector-match-test.sh # therefore FAILS a chart that has an overlay and still renders no selector. # # This is a RENDER-ONLY overlay. Nothing here is installed anywhere, so the two # reasons the install-test keeps mx at 0 do not apply. nodes: full: replicas: 2 exposedPorts: [smtp, submissions, imaps, http] mx: # Two as well, so BOTH groups' selectors are checked. The per-group split is # the whole point of this chart's version of the rule: one object per group, # each selecting only its own pods. A single group would leave the case where # a group's selector accidentally matches the OTHER group's pods untested. replicas: 2 exposedPorts: [smtp, http] externalServices: valkey: # REQUIRED HERE, and not cosmetic: with more than one Stalwart pod and no # in-memory store address the chart ABORTS THE RENDER ("this release runs N # Stalwart pods, which is a cluster, but no in-memory store has an # address"). Nothing connects to this name - the render never resolves it - # but without it this overlay would turn the whole job red instead of # exercising it. valkeySubchart.enabled: true would be the other way out and # is deliberately not taken: it would add a network fetch of the published # valkey chart to a test that otherwise needs none. host: valkey-selector-match-fixture