# Render-only overlay for ci/run-httproute-match-test.sh, applied LAST.
#
# Its one job is to put this chart into Gateway mode, because the convention
# ships with httpRoute.enabled: false and the test would otherwise be green
# over nothing. A chart that has an overlay here and still renders no
# HTTPRoute FAILS the test - that is the whole point of the file existing.
#
# An overlay and not a change to ci/stalwart/test-values.yaml: the install-test
# runs exactly ONE configuration per chart, and this chart's fixture brings up
# the node groups against a throwaway Postgres. Trading its Ingress for a CRD
# schema check that cyberchef's fixture already performs against the real
# Gateway-API CRDs would be a bad swap. The install keeps the Ingress; the
# route is held here, at render level, which is where its silent failure modes
# live.
#
# ingress.enabled: false is not optional here - ingress.enabled is this chart's
# HTTP routing switch and defaults to TRUE, so without this line the chart
# aborts its own render with both modes on.
#
# WHAT THIS OVERLAY COVERS:
#
#   - ingress.domain comes from the fixture, so the route renders with its
#     hostname from that single source of truth. httpRoute.hostnames stays
#     empty on purpose: the fallback is the path every installation will
#     actually use.
#   - ingress.nodeGroup comes from the fixture too, so the route is checked to
#     point at THAT GROUP'S http Service and no other. This chart is the one in
#     group 3 where the backend is group-scoped, and the ONE-route-not-one-
#     per-group property is exactly what would be easy to get wrong on a copy.
#   - the backendRef is checked against the per-group http Service of the same
#     render, by PORT NUMBER (ports.http.containerPort) rather than by the name
#     "http" the Ingress uses, because backendRefs takes a PortNumber. Note
#     that this chart's NodePort Services publish a DIFFERENT number
#     (ports.<name>.nodePort) than the container binds, so naming the wrong one
#     here would be a plausible mistake - this overlay is what catches it.
#
# No URLRewrite filter is rendered by this chart in either mode, so the #118
# prefix/redirect assurance has no precondition to meet here.
#
# NOT covered here, and none of it can be:
#
#   - that the hostname answers. No Gateway controller runs in CI and no route
#     reaches "Accepted: True".
#   - THE CORS CONFIGURATION, which is the thing this chart actually loses in
#     this mode and the one that breaks the bulwark webmail. It lives in the
#     operator's ingress.annotations, the chart has no values for it, and the
#     Gateway API's own CORS filter is Extended-support with observed
#     implementation variance - all of which is documented in values.yaml and
#     printed by NOTES.txt. Documentation is not something a test can assert.
#   - that SMTP/IMAP still work. They never went through the Ingress and do not
#     go through the route; the mail Certificate that serves them keeps being
#     rendered in this mode, which is this chart's distinguishing feature in
#     the sweep, and no render test looks at whether it was left alone.
ingress:
  enabled: false
httpRoute:
  enabled: true
  parentRefs:
    - name: public
      namespace: gateway
      sectionName: https