# 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/ytdlp-web-player/test-values.yaml: the
# install-test runs exactly ONE configuration per chart, and this chart's
# fixture is the one that resolves and installs the oauth2-proxy SUBCHART.
# 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.
#
# ingress.enabled: false is not optional here - ingress.enabled defaults to
# TRUE in this chart, so without this line the chart aborts its own render with
# both modes on.
#
# THE SUBCHART IS LEFT DISABLED, as the fixture has it, and that is deliberate
# rather than lazy. The oauth2-proxy chart HAS NO GATEWAY-API SUPPORT - it
# renders an Ingress or nothing - so switching it on here would add a second
# object this test does not look at, while the thing worth exercising in
# Gateway mode is this chart's own route. The interesting interaction between
# the two (one hostname claimed by the proxy's Ingress AND by this chart's
# HTTPRoute, which the ingress-nginx admission webhook cannot catch because the
# kinds differ) is a RENDER-FAILURE path: the chart refuses it. This test only
# runs renders it expects to succeed, so that guard was exercised by hand
# instead - see the PR.
#
# WHAT THIS OVERLAY COVERS:
#
#   - ingress.domain comes from the fixture (ytdlp-web-player.example.com), so
#     the route renders with its hostname from that single source of truth.
#     httpRoute.hostnames stays empty on purpose: the fallback is the path an
#     installation will actually use.
#   - the backendRef is checked against the application Service of the same
#     render, by PORT NUMBER rather than by the name "http" the Ingress uses,
#     because backendRefs takes a PortNumber. That number also has to agree
#     with ytdlp-web-player.appServiceAddress, which is what the proxy gets as
#     its upstream - three places, and this overlay holds two of them together.
#
# 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 it cannot be:
#
#   - that the hostname answers. No Gateway controller runs in CI and no route
#     reaches "Accepted: True".
#   - that authentication is in front of the application. With the proxy off
#     this route IS the unauthenticated path, which is correct for a fixture
#     and is exactly what NOTES.txt warns about for a real installation.
#   - anything about how this release is published in the real cluster. There
#     is no live Ingress of this chart to compare against: measured 2026-10-12,
#     the release runs in namespace jlab-player with both Deployments Ready and
#     not one of the cluster's 23 Ingress objects is in that namespace. What
#     publishes it could not be determined from the workspace.
ingress:
  enabled: false
httpRoute:
  enabled: true
  parentRefs:
    - name: public
      namespace: gateway
      sectionName: https