# 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 note on this chart's install-test, because it has a history. It had failed
# on the Gitea runner since the move - php-fpm unable to read /app/index.php,
# the startup probe 403ing through its whole budget, the pod never Ready (Gitea
# #51), reproduced on two images while the same chart and image ran healthy in
# the cluster. The chart was deliberately kept OUT of ci/excluded-charts.txt so
# that a pass would be noticed rather than silenced, and in the PR that added
# this overlay it PASSED: pod 1/1 Ready in 22s, 0 restarts, no permission error
# in the job. Since that PR's rendered defaults are byte-identical to
# origin/main, the chart is ruled out as the cause and the runner is the
# implicated layer - which is where #51 had already placed it. It reproduced
# on every run of that branch since, so it is not a fluke; but nobody has
# identified what changed on the runner, so #51 is not closed on the strength
# of a colour.
#
# Either way this overlay stays load-bearing: the install-test installs the
# INGRESS mode (that is what the fixture sets), so the Gateway mode of this
# chart is covered here at render level and nowhere else - the same situation
# as every other chart in the sweep.
#
# 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