# 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/rss-bridge/test-values.yaml, and for this
# chart the reason is sharper than for its siblings. The install-test runs
# exactly ONE configuration per chart and the two modes are mutually exclusive,
# so switching the fixture would trade this chart's Ingress away - and that
# fixture's Ingress is the only thing that exercises rss-bridge.tlsGroups, the
# secret-grouping helper that keeps the three grown certificates of the real
# installation on their existing names. That helper is inert in Gateway mode
# (nothing to group once TLS sits on the listener), so a fixture switched to
# this mode would stop covering it entirely. The CRD schema check the pilot
# paid for is already performed by cyberchef's fixture against the real
# Gateway-API CRDs; what is missing without this file is the render-level
# assurance, and that is what this overlay buys.
#
# A caveat that applies to this chart and to no other in the sweep: its
# install-test does not pass at all. php-fpm cannot read /app/index.php on the
# Gitea runner, the startup probe 403s through its whole budget and the pod
# never becomes Ready (Gitea #51 - reproduced on two different images, while
# the same chart and image run healthy in the cluster, so the defect is the
# runner's). The chart is deliberately NOT in ci/excluded-charts.txt: an
# exclusion would silence the signal, and the day the runner is fixed this test
# goes green by itself and that is how anyone will find out. So for this chart
# the render-level assurances below are the ONLY automated coverage its Gateway
# mode has.
#
# ingress.enabled: false is not optional here - the chart ships it as TRUE and
# aborts its own render when both modes are on.
#
# httpRoute.hostnames MUST be supplied, and this overlay is the second in the
# repository that has to (homeassistant's was the first). The other charts let
# an empty hostnames list fall back to ingress.domain; this chart has no
# ingress.domain, and it deliberately does not reuse ingress.hosts from the
# fixture, because those entries carry tlsSecretName values that address
# nothing once the certificate sits on the Gateway's listener. The render
# aborts on an empty list rather than publishing a route that matches every
# request reaching its listener.
#
# THREE hostnames on ONE object, which is the shape this chart's production
# installation has (three hosts, all serving the same Service at "/"). It is
# also the shape the test should see: one HTTPRoute, one rule, one backendRef,
# several hostnames - as opposed to homeassistant's one-object-per-host or
# matrix-synapse's two objects with different paths and backends. The three
# names are kept recognisably parallel to ci/rss-bridge/test-values.yaml so the
# two modes can be read side by side, but they are NOT the same values: these
# are the route's hostnames, and the fixture's are the Ingress's hosts.
ingress:
  enabled: false
httpRoute:
  enabled: true
  parentRefs:
    - name: public
      namespace: gateway
      sectionName: https
  hostnames:
    - rss-bridge.ci.local
    - rssbridge.ci.local
    - rss-bridge.ci.example