jklein
f6eeff87c2
Group 3 of the #114 sweep. One route, one rule, at the root - and THREE EXPECTATIONS ABOUT THIS CHART DID NOT SURVIVE CONTACT WITH IT: - #114 says bulwark has TWO Ingress objects. It has ONE. keycloak has two. - #114's measured table lists bulwark under rewrite-target. It has no rewrite-target annotation and CANNOT have one: NEXT_PUBLIC_BASE_PATH is compiled into the bundle, so the application cannot be served under a sub-path, and stripping a prefix at the proxy would yield a page that loads and then fetches everything from the wrong place. Every occurrence of the string "rewrite-target" in this chart - values.yaml, the schema, the Ingress template - is an explanation of exactly that. A grep for the string finds the refutations and counts them as occurrences. - ci/run-httproute-match-test.sh said in its header that bulwark was the second rewrite-target chart and would meet the #118 prefix/redirect assurance when group 3 landed. Group 3 landed and it does not: with no URLRewrite on a prefix other than "/", the assurance's precondition is never met here. The header is corrected rather than left standing, and it now says freesailarr is the only chart the pairing applies to. So no redirect rule is added, and none is needed. WHAT THIS MODE DROPS, MEASURED ON THE LIVE OBJECT rather than inferred. On 2026-10-12 the live Ingress on webmail.bekemeyer-klein.de carried nginx.ingress.kubernetes.io/proxy-body-size: 25m supplied by the OPERATOR through ingress.annotations - values.yaml recommends exactly that value and explains why the chart cannot pick it, so the chart sets nothing and a reader of this repository alone would not find it. It is the single annotation this installation depends on, and the Gateway API has no body-size counterpart: implementation policy, not routing. Per decisions 1 and 2 of #114 it is NAMED, not rebuilt - in values.yaml, in the schema and in the Gateway branch of NOTES.txt, in this application's own terms: an attachment above the Gateway's default is rejected before Bulwark sees a byte, the 413 comes from the proxy, and it arrives after the user has written the mail and attached the file. CORRECTED CLAIM, the same one garage and calibre-web-automated needed: the Ingress template, the bulwark.publicUrl helper and the schema all stated that nothing outside the Ingress template FUNCTIONALLY reads ingress.domain. The HTTPRoute reads it, so the claim held only while both modes were off. All three now say so, and the route carries a required() of its own. bulwark.publicUrl follows the ACTIVE mode instead of always printing ingress.domain. The two differ exactly when httpRoute.hostnames is set, which is how a migration off the Ingress runs - and printing the old host there would hand the operator an OIDC redirect URI for the hostname being migrated away from, a failure that surfaces as a rejected login at the identity provider and says nothing about this chart. Minor: additive, defaults unchanged. Empty helm template diff against origin/main with ci/bulwark/test-values.yaml. Part of #114
55 lines
2.7 KiB
YAML
55 lines
2.7 KiB
YAML
# 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/bulwark/test-values.yaml: the install-test
|
|
# runs exactly ONE configuration per chart, and this chart's fixture installs
|
|
# the StatefulSet with its PVC and both 1Password items. 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, which is where its silent failure modes
|
|
# live.
|
|
#
|
|
# ingress.enabled: false is not optional here - ingress.enabled is this chart's
|
|
# routing switch and defaults to TRUE, so without this line the chart aborts
|
|
# its own render with both modes on.
|
|
#
|
|
# ONE ROUTING OBJECT, WHICH IS ALL THIS CHART HAS. #114's measured table and
|
|
# the header of ci/run-httproute-match-test.sh both expected two Ingresses and
|
|
# a rewrite-target here; neither is the case, and the reason is in
|
|
# bulwark.httproute.yaml. In short: Bulwark cannot be served under a sub-path
|
|
# (NEXT_PUBLIC_BASE_PATH is compiled into the bundle), so there is one object,
|
|
# one rule, at "/", and no URLRewrite filter for the #118 prefix/redirect
|
|
# assurance to pair up with. Every "rewrite-target" string in this chart is an
|
|
# explanation of why it does not work, and a grep counted those as
|
|
# occurrences.
|
|
#
|
|
# WHAT THIS OVERLAY COVERS:
|
|
#
|
|
# - ingress.domain comes from the fixture, so the route renders with its
|
|
# hostname from that single source of truth - httpRoute.hostnames stays
|
|
# empty on purpose, because the fallback is the path every installation
|
|
# will actually use.
|
|
# - the route's backendRef is checked against the serving Service of the same
|
|
# render, by PORT NUMBER (bulwark.port) rather than by the name "http" the
|
|
# Ingress uses, because backendRefs takes a PortNumber. This overlay is
|
|
# what holds that number against the Service's.
|
|
#
|
|
# NOT covered here, and it cannot be: that the hostname answers. No Gateway
|
|
# controller runs in CI and no route reaches "Accepted: True". Nor the thing
|
|
# this chart actually loses in this mode - the operator's
|
|
# proxy-body-size: 25m, which has no counterpart in the specification. 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
|