# 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/keycloak/test-values.yaml: the install-test # runs exactly ONE configuration per chart, and this chart's fixture is the # expensive and informative one - two replicas against a throwaway PostgreSQL, # two init containers, `kc.sh build` under readOnlyRootFilesystem, and the # Infinispan cluster forming over jdbc-ping (see that file for the four things # only a real install can prove). Trading all of it 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 two Ingresses; the two routes are held # here, at render level, which is where their silent failure modes live. # # ingress.enabled: false is not optional here. The two modes are mutually # exclusive and the chart aborts its own render when both are true, so an # overlay that only switched httpRoute on would turn this test red. # # WHAT THIS OVERLAY COVERS, WHICH IS BOTH ROUTING OBJECTS: # # - ingress.domain comes from the fixture (keycloak.ci.example.com), so the # PUBLIC route renders with its hostname from that single source of truth # (httpRoute.hostnames stays empty on purpose - the fallback is the path # that every installation will actually use). # - ingress.admin.enabled is true in the fixture with # ingress.admin.domain set, so the ADMIN route renders too, and its # parentRefs fall back to httpRoute.parentRefs below - the empty-admin # branch, which is the one an installation hits unless it wants an # internal Gateway. # - every route's backendRef is checked against the serving Service of the # same render. They all point at the SAME Service, by PORT NUMBER # (keycloak.ports.http) rather than by the name "http" the Ingress uses, # because backendRefs takes a PortNumber - so this overlay is what holds # that number against the Service's. # - THE TWO REALM ROUTES (Gitea #122), which come from keycloak.realmHosts in # the fixture rather than from this file. Nothing is repeated here on # purpose: the fixture installs them as Ingress objects and this overlay # turns the same two entries into HTTPRoutes, so one definition covers both # modes and the two halves cannot drift into describing different hostnames. # What the routes add to the two above is a SECOND RULE SHAPE - an Exact # match on / carrying a RequestRedirect filter and no backendRefs at all. # That rule is reported as "not checked" by this test, correctly and by # design: a filter-only rule has no backend to resolve. The assertion it # does earn is on its sibling rule, the PathPrefix one that points at the # Service. The prefix/redirect pairing check of #118 does NOT fire for these # routes and must not: it is scoped to rules that STRIP a prefix with a # ReplacePrefixMatch rewrite, and these strip nothing - they redirect the # bare root of a hostname that serves one realm. # The entries also cover the two Ingress-mode forms (one with a # clusterIssuer, one without) and what this test holds about them is their # INERTNESS: neither tlsSecretName nor clusterIssuer nor the per-entry # annotation may appear anywhere in a rendered route. # # NOT covered here, and it cannot be: that either hostname answers. No Gateway # controller runs in CI, no route reaches "Accepted: True", and the # proxy-buffer-size/proxy-buffers-number annotations this chart's live # installation relies on have no counterpart in this mode at all - that loss is # documented in values.yaml and printed by NOTES.txt, and documentation is not # something a test can assert. ingress: enabled: false httpRoute: enabled: true parentRefs: - name: public namespace: gateway sectionName: https