# 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.
#   - THE MTA-STS ROUTE (Gitea #123), which is the second HTTPRoute this chart
#     renders. Its backendRef is held against the same per-group http Service
#     by the same port number, so the one place information travels from the
#     Service object into a route template is checked twice rather than once.
#     What the list below is shaped for is the three cases the entry form has:
#     an entry WITH a clusterIssuer, an entry WITHOUT one, and a host on a
#     SUBDOMAIN - the last because mta-sts.sub.<domain> is one label deeper
#     than *.<domain> and a parent wildcard does not cover it.
#
#     Both TLS fields are INERT IN THIS MODE: TLS sits on the Gateway's
#     listener and this chart renders no certificate for an HTTP hostname
#     here. They are set anyway, and that is the assertion - the render has to
#     ACCEPT them in Gateway mode without requiring them, because the mirror
#     image (tlsSecretName required in Ingress mode) is what makes them
#     mode-specific rather than optional-everywhere.
#
#     The Ingress half of this feature is NOT exercised here - this overlay's
#     whole job is to switch the mode off. It is exercised by
#     ci/stalwart/test-values.yaml instead, which installs in Ingress mode and
#     therefore has the MTA-STS Ingress objects accepted by a real API server.
ingress:
  enabled: false
httpRoute:
  enabled: true
  parentRefs:
    - name: public
      namespace: gateway
      sectionName: https
mtaSts:
  hosts:
    - host: mta-sts.ci.example.com
      tlsSecretName: tls-mta-sts-ci-example-com-ingress
      clusterIssuer: ci-selfsigned
    # One label deeper: its own secret, because the parent's wildcard would not
    # reach it. In this mode that is the Gateway listener's problem, which is
    # exactly why the entry is here and why the values are inert.
    - host: mta-sts.sub.ci.example.com
      tlsSecretName: tls-mta-sts-sub-ci-example-com-ingress
      clusterIssuer: ci-selfsigned
    # No clusterIssuer: "the certificate comes from somewhere else". Nothing in
    # this mode reads it either way; the point is that the render accepts the
    # entry without it.
    - host: mta-sts.other.ci.example
      tlsSecretName: tls-some-existing-wildcard-ingress