# cyberchef: stateless, no secrets.
#
# THIS CHART IS INSTALLED IN GATEWAY MODE, NOT IN INGRESS MODE (Gitea #114),
# and that is a deliberate trade, because the install-test runs exactly ONE
# configuration per chart and the two modes are mutually exclusive.
#
# What is given up: the Ingress of this one chart is no longer installed
# anywhere. That costs little. An Ingress is a built-in, GA type whose schema
# the API server has validated for a decade, k3d's own ingress controller is
# traefik while this chart asks for the class "nginx", so nothing ever routed
# through it here either - the install only ever proved "the API server
# accepted an Ingress". And it keeps being proved, twenty times over, by every
# other chart in the repo plus `helm lint --strict`, which renders this chart's
# DEFAULTS, i.e. Ingress mode, on every pull request.
#
# What is gained: a real HTTPRoute, applied against the real Gateway-API CRDs
# (see ci/gateway-api-crds.sh), which is a CRD whose schema nothing else in
# this repository has ever exercised. That is where a malformed parentRefs or
# backendRefs is actually caught.
#
# Still NOT proved by this, and it cannot be: that traffic flows. No Gateway
# controller runs in k3d, so nothing routes. The install-test proves the object
# is schema-valid and the pod becomes Ready; ci/run-httproute-match-test.sh
# proves the route points at a Service the same render creates.
ingress:
  # The hostname is read by the HTTPRoute too (httpRoute.hostnames is empty, so
  # it falls back to ingress.domain) - it is the release's public name, not an
  # Ingress switch.
  domain: cyberchef.ci.local
  enabled: false
httpRoute:
  enabled: true
  # The Gateway does not exist in the CI cluster, and it does not need to: a
  # parentRef is resolved by the Gateway controller, of which there is none
  # here, so the reference is stored as written. What the real CRDs DO validate
  # is its shape.
  parentRefs:
    - name: ci-gateway
      namespace: default
      sectionName: https