Pilot of #114: the Gateway API as an alternative to the Ingress, in one chart plus the convention and the CI that holds it. The remaining 20 charts are a separate undertaking — Part of #114, not Fixes, because the issue asks for all in-house charts and this delivers one.
The form
httpRoute:enabled:false# counterpart to ingress.enabled, default offparentRefs:[]# the Gateway (name/namespace/sectionName) — a platform objecthostnames:[]# empty = [ingress.domain]
Only HTTPRoute with parentRefs is rendered. No Gateway, nogatewayClassName, no certificate, no implementation-specific policy object (ClientSettingsPolicy, ClientTrafficPolicy). That subset looks identical on nginx-gateway-fabric, Cilium, Envoy Gateway and Istio — which is the whole point: the implementation decision can still fall later without touching the charts again. Class and certificate move to the platform (Gateway listeners, cluster-config).
Four guards, each against something that fails without reporting itself:
Guard
Why
mutually exclusive with ingress.enabled, render abort naming both value paths
two paths onto one Service under one hostname is a conflict at DNS level already; a migration runs over a second hostname
parentRefs mandatory in Gateway mode, render abort on the empty list
a route without a parent is created, is schema-valid, is rejected by nobody and routes nothing — no event, no condition
hostnames empty = [ingress.domain]
two values that must agree drift apart
the mode is a value, not auto-detection
.Capabilities.APIVersions is unreliable at template time, and a missing CRD fails at install time
NOTES.txt names the active mode and what it costs — including that ingress.annotations has no counterpart at all, which for this chart is sharper than it sounds: CyberChef has no login, and the chart's own advice so far was "put auth in front of it via ingress.annotations". In Gateway mode that escape hatch does not exist in the chart, and the note says so instead of leaving an open instance behind a sentence that no longer applies.
One finding on the plan, reported rather than silently implemented
ingress.clusterIssuer "becomes conditionally required" is a no-op for this chart: both of its reads already sit inside cyberchef.ingress.yaml, behind ingress.enabled, and values.yaml already documented that. Nothing was changed for it and nothing needed to be. The sweep has to re-check this per chart rather than inherit the conclusion — README guideline 12, point 1 is about exactly this class of read, and template-chart is the counter-example in the same PR: its env block reads ingress.domain, so there the value stays required with the Ingress off.
The fixture decision, and what it gives up
ci/cyberchef/test-values.yaml now installs in Gateway mode. The install-test runs one configuration per chart and the two modes are mutually exclusive, so this is a trade and not a free addition.
Given up: the Ingress of this one chart is no longer installed anywhere. That costs little, measurably so — an Ingress is a built-in GA type the API server has validated for a decade, k3d's own controller is traefik while this chart asks for class nginx, so nothing ever routed through it here either; the install only proved "the API server accepted an Ingress". It keeps being proved by 20 other charts, and helm lint --strict renders this chart's defaults — Ingress mode — on every PR.
Gained: a real HTTPRoute, applied against the real Gateway-API CRDs, which is a schema nothing in this repository has ever exercised. That is where a malformed parentRefs or backendRefs is actually caught.
The CRDs: real, pinned, server-side — and not in ci/common/
ci/gateway-api-crds.sh fetches the standard channel at v1.6.3 (pinned, with a # renovate: comment and a new customManager for ci/*.sh) and applies it with kubectl apply --server-side. Called from ci/run-install-test.sh only when the chart's render actually contains an HTTPRoute — detected from the render, so there is no list to maintain and the sweep enrols a chart by switching its fixture.
Three decisions worth the review, each with its measurement:
Not a stub.ci/common/'s schema-less OnePasswordItem CRD is right for its job (nobody is testing the operator's API). For an HTTPRoute the schema is the job: a stub would accept a malformed parentRefs, a port written as a string, a path type that does not exist — and the install-test would prove only that something was created.
--server-side, and not out of taste. Client-side apply stores the whole object in last-applied-configuration; annotations total at most 262144 bytes; the HTTPRoute CRD of v1.6.3 is 429367 bytes of YAML, 244792 bytes as JSON (measured by re-reading it through ci/yaml2json). That is 93 % of the limit with every release adding fields — client-side happens to fit today and is one upstream release away from metadata.annotations: Too long on a Renovate PR that has nothing to do with it.
Not in ci/common/, which is applied client-side for every chart: putting it there would hand that landmine to all 20-odd charts and spend the download on charts that render no route.
It also waits for condition=Established rather than for the object to exist — helm install in that window fails with no matches for kind HTTPRoute, which reads like a missing CRD rather than like a race.
The CI assurance, and what its fail path caught
ci/run-httproute-match-test.sh, modelled on ci/run-selector-match-test.sh (#96) down to the Helm-as-YAML-parser mechanics, since the runners have neither pyyaml nor yq. Over every chart on every PR, as the new httproute-match job: every backendRefs entry must name a Service, on a port, that the same render creates, and parentRefs must not be empty.
The real CRDs do not close either gap — that is why this job exists next to them. The Gateway-API schema accepts an empty parentRefs list and a backendRefs entry pointing at a Service that was never created. The CRDs prove the object is well-formed; this test proves it points somewhere.
The port half is a genuinely new exposure rather than a hypothetical: an Ingress backend references its Service port by name, while backendRefs takes a PortNumber and cannot — so the number in the route and the port in the Service are kept in step by hand from now on.
Anti-vacuum, because this test can be green over nothing (the convention ships enabled: false): overlays under ci/httproute/<chart>.yaml, a chart that has one and renders no route fails, and a run with zero assertions fails.
The fail path was driven, not assumed. Six runs in a throwaway copy, each producing a FAIL naming both sides and exit 1:
Injected
Caught as
Service renamed in the route (-service → -svc)
references Service 'httproute-cyberchef-svc', which the SAME render does not create … Services this render does create: httproute-cyberchef-service
route port 8080, Service serves 80
references Service … on port 8080, which that Service does not expose (it serves 80)
port: line deleted
references Service … without a port. A backendRef to a Service must carry one — the CRD schema cannot require it conditionally
parentRefs: [] with the chart's own guard disabled
has an empty list of parentRefs. A route without a parent attaches to NO Gateway …
overlay present, chart put back into Ingress mode
has an overlay at ci/httproute/cyberchef.yaml but rendered no HTTPRoute, so nothing was checked
no chart in the run renders a route
not a single HTTPRoute assertion was checked in this run … A pass over zero assertions is not a pass
Measured clean: 27 charts, 4 assertions held in ~3 s, no cluster.
What remains unprovable, and is stated instead of implied
That traffic flows. No Gateway controller runs in k3d, so no route is ever reconciled, no status is ever written, nothing routes. What the pipeline does prove: the object is schema-valid (install-test, real CRDs) and the pod becomes Ready, and the route points at a Service and a port the same render creates (render test). Accepted: True is not obtainable here and is claimed nowhere.
helm template against defaults and against the fixture values, in all three modes (Ingress / Gateway / neither).
The Minor proof: an empty helm template diff against origin/main for the default values — 119 lines each, byte-identical.
ci/run-quantity-render-test.sh cyberchef template-chart — both cases exercised the helper, no exponential notation.
ci/run-selector-match-test.sh on both charts — unchanged (neither renders a selector).
ci/run-httproute-match-test.sh over all charts, plus the six fail paths above.
Schema in both directions: a valid Gateway-mode values file passes; parentRefs[0] without name is rejected with missing property 'name'; an unknown key under httpRoute with additional properties 'parentRef' not allowed.
Render aborts exercised: both modes on, empty parentRefs, no hostname at all. And --set httpRoute=null still renders cleanly (null-safe per #99) instead of a nil-pointer abort.
NOTES.txt rendered in every branch via the documented define + scratch-ConfigMap trick, since helm template does not render NOTES.txt.
renovate.json5 parsed and the new customManager regex matched against the real script (datasource=github-releases, depName=kubernetes-sigs/gateway-api, currentValue=v1.6.3).
Not checked here, and named as such: no k3d, no Docker and no Trivy in the authoring environment — so the install-test, the --server-side apply and the trivy config scan are proven by CI only, not locally. The three charts with a Helm dependency could not be rendered locally either (the private registry is unreachable from there — the same limitation the existing selector-match test has), so their legs of the new render test are first exercised by CI. The new customManager is not dry-run verified against Renovate; the regex match is tested, the lookup is not.
Wiki
Chart-Style-Guide (the convention), CI-CD (the new job and the CRD fixture), cyberchef (the new values and the two modes) and Lessons-Learned (a schema-less stub CRD makes an install-test prove nothing — repeatable wherever the next CRD arrives).
Pilot of #114: the Gateway API as an alternative to the Ingress, in **one** chart plus the convention and the CI that holds it. The remaining 20 charts are a separate undertaking — `Part of #114`, not `Fixes`, because the issue asks for all in-house charts and this delivers one.
## The form
```yaml
httpRoute:
enabled: false # counterpart to ingress.enabled, default off
parentRefs: [] # the Gateway (name/namespace/sectionName) — a platform object
hostnames: [] # empty = [ingress.domain]
```
Only `HTTPRoute` with `parentRefs` is rendered. **No** Gateway, **no** `gatewayClassName`, **no** certificate, **no** implementation-specific policy object (`ClientSettingsPolicy`, `ClientTrafficPolicy`). That subset looks identical on nginx-gateway-fabric, Cilium, Envoy Gateway and Istio — which is the whole point: the implementation decision can still fall later without touching the charts again. Class and certificate move to the **platform** (Gateway listeners, `cluster-config`).
Four guards, each against something that fails without reporting itself:
| Guard | Why |
|---|---|
| mutually exclusive with `ingress.enabled`, render abort naming **both** value paths | two paths onto one Service under one hostname is a conflict at DNS level already; a migration runs over a **second hostname** |
| `parentRefs` mandatory in Gateway mode, render abort on the empty list | a route without a parent is created, is schema-valid, is rejected by nobody and routes **nothing** — no event, no condition |
| `hostnames` empty = `[ingress.domain]` | two values that must agree drift apart |
| the mode is a **value**, not auto-detection | `.Capabilities.APIVersions` is unreliable at template time, and a missing CRD fails at *install* time |
`NOTES.txt` names the active mode and what it costs — including that `ingress.annotations` has no counterpart at all, which for *this* chart is sharper than it sounds: CyberChef has no login, and the chart's own advice so far was "put auth in front of it via `ingress.annotations`". In Gateway mode that escape hatch does not exist in the chart, and the note says so instead of leaving an open instance behind a sentence that no longer applies.
## One finding on the plan, reported rather than silently implemented
`ingress.clusterIssuer` "becomes conditionally required" is a **no-op for this chart**: both of its reads already sit inside `cyberchef.ingress.yaml`, behind `ingress.enabled`, and `values.yaml` already documented that. Nothing was changed for it and nothing needed to be. The sweep has to re-check this per chart rather than inherit the conclusion — README guideline 12, point 1 is about exactly this class of read, and `template-chart` is the counter-example in the same PR: its `env` block reads `ingress.domain`, so there the value stays required with the Ingress off.
## The fixture decision, and what it gives up
**`ci/cyberchef/test-values.yaml` now installs in Gateway mode.** The install-test runs one configuration per chart and the two modes are mutually exclusive, so this is a trade and not a free addition.
Given up: the Ingress of this one chart is no longer *installed* anywhere. That costs little, measurably so — an `Ingress` is a built-in GA type the API server has validated for a decade, k3d's own controller is traefik while this chart asks for class `nginx`, so nothing ever routed through it here either; the install only proved "the API server accepted an Ingress". It keeps being proved by 20 other charts, and `helm lint --strict` renders this chart's **defaults** — Ingress mode — on every PR.
Gained: a real `HTTPRoute`, applied against the **real** Gateway-API CRDs, which is a schema nothing in this repository has ever exercised. That is where a malformed `parentRefs` or `backendRefs` is actually caught.
## The CRDs: real, pinned, server-side — and not in `ci/common/`
`ci/gateway-api-crds.sh` fetches the **standard channel at `v1.6.3`** (pinned, with a `# renovate:` comment and a new `customManager` for `ci/*.sh`) and applies it with `kubectl apply --server-side`. Called from `ci/run-install-test.sh` only when the chart's render actually contains an `HTTPRoute` — detected from the render, so there is no list to maintain and the sweep enrols a chart by switching its fixture.
Three decisions worth the review, each with its measurement:
- **Not a stub.** `ci/common/`'s schema-less `OnePasswordItem` CRD is right for its job (nobody is testing the operator's API). For an `HTTPRoute` the schema **is** the job: a stub would accept a malformed `parentRefs`, a port written as a string, a path type that does not exist — and the install-test would prove only that *something was created*.
- **`--server-side`, and not out of taste.** Client-side apply stores the whole object in `last-applied-configuration`; annotations total at most **262144** bytes; the HTTPRoute CRD of v1.6.3 is **429367** bytes of YAML, **244792** bytes as JSON (measured by re-reading it through `ci/yaml2json`). That is 93 % of the limit with every release adding fields — client-side happens to fit *today* and is one upstream release away from `metadata.annotations: Too long` on a Renovate PR that has nothing to do with it.
- **Not in `ci/common/`**, which is applied **client-side for every chart**: putting it there would hand that landmine to all 20-odd charts and spend the download on charts that render no route.
It also waits for `condition=Established` rather than for the object to exist — `helm install` in that window fails with `no matches for kind HTTPRoute`, which reads like a missing CRD rather than like a race.
## The CI assurance, and what its fail path caught
`ci/run-httproute-match-test.sh`, modelled on `ci/run-selector-match-test.sh` (#96) down to the Helm-as-YAML-parser mechanics, since the runners have neither `pyyaml` nor `yq`. Over **every** chart on **every** PR, as the new `httproute-match` job: every `backendRefs` entry must name a **Service, on a port, that the same render creates**, and `parentRefs` must not be empty.
**The real CRDs do not close either gap** — that is why this job exists next to them. The Gateway-API schema accepts an empty `parentRefs` list and a `backendRefs` entry pointing at a Service that was never created. The CRDs prove the object is *well-formed*; this test proves it *points somewhere*.
The port half is a genuinely new exposure rather than a hypothetical: an Ingress backend references its Service port **by name**, while `backendRefs` takes a `PortNumber` and cannot — so the number in the route and the port in the Service are kept in step by hand from now on.
Anti-vacuum, because this test can be green over nothing (the convention ships `enabled: false`): overlays under `ci/httproute/<chart>.yaml`, a chart that **has** one and renders no route **fails**, and a run with zero assertions fails.
**The fail path was driven, not assumed.** Six runs in a throwaway copy, each producing a `FAIL` naming both sides and exit 1:
| Injected | Caught as |
|---|---|
| Service renamed in the route (`-service` → `-svc`) | `references Service 'httproute-cyberchef-svc', which the SAME render does not create … Services this render does create: httproute-cyberchef-service` |
| route port `8080`, Service serves `80` | `references Service … on port 8080, which that Service does not expose (it serves 80)` |
| `port:` line deleted | `references Service … without a port. A backendRef to a Service must carry one — the CRD schema cannot require it conditionally` |
| `parentRefs: []` with the chart's own guard disabled | `has an empty list of parentRefs. A route without a parent attaches to NO Gateway …` |
| overlay present, chart put back into Ingress mode | `has an overlay at ci/httproute/cyberchef.yaml but rendered no HTTPRoute, so nothing was checked` |
| no chart in the run renders a route | `not a single HTTPRoute assertion was checked in this run … A pass over zero assertions is not a pass` |
Measured clean: 27 charts, **4 assertions held in ~3 s**, no cluster.
## What remains unprovable, and is stated instead of implied
**That traffic flows.** No Gateway controller runs in k3d, so no route is ever reconciled, no status is ever written, nothing routes. What the pipeline does prove: the object is **schema-valid** (install-test, real CRDs) and the pod becomes **Ready**, and the route **points at a Service and a port the same render creates** (render test). `Accepted: True` is not obtainable here and is claimed nowhere.
## Verification run locally
- `helm lint --strict cyberchef` / `template-chart` — 0 failed; `helm package` both.
- `helm template` against **defaults** and against the **fixture values**, in all three modes (Ingress / Gateway / neither).
- **The Minor proof: an empty `helm template` diff against `origin/main`** for the default values — 119 lines each, byte-identical.
- `ci/run-quantity-render-test.sh cyberchef template-chart` — both cases exercised the helper, no exponential notation.
- `ci/run-selector-match-test.sh` on both charts — unchanged (neither renders a selector).
- `ci/run-httproute-match-test.sh` over all charts, plus the six fail paths above.
- Schema in **both** directions: a valid Gateway-mode values file passes; `parentRefs[0]` without `name` is rejected with `missing property 'name'`; an unknown key under `httpRoute` with `additional properties 'parentRef' not allowed`.
- Render aborts exercised: both modes on, empty `parentRefs`, no hostname at all. And `--set httpRoute=null` still renders cleanly (null-safe per #99) instead of a nil-pointer abort.
- `NOTES.txt` rendered in every branch via the documented `define` + scratch-ConfigMap trick, since `helm template` does not render `NOTES.txt`.
- `renovate.json5` parsed and the new `customManager` regex matched against the real script (`datasource=github-releases`, `depName=kubernetes-sigs/gateway-api`, `currentValue=v1.6.3`).
**Not checked here, and named as such:** no k3d, no Docker and no Trivy in the authoring environment — so the install-test, the `--server-side` apply and the `trivy config` scan are proven by **CI only**, not locally. The three charts with a Helm dependency could not be rendered locally either (the private registry is unreachable from there — the same limitation the existing selector-match test has), so their legs of the new render test are first exercised by CI. The new `customManager` is **not** dry-run verified against Renovate; the regex match is tested, the lookup is not.
## Wiki
`Chart-Style-Guide` (the convention), `CI-CD` (the new job and the CRD fixture), `cyberchef` (the new values and the two modes) and `Lessons-Learned` (a schema-less stub CRD makes an install-test prove nothing — repeatable wherever the next CRD arrives).
Part of #114
The Gateway-API pilot of Gitea #114: one chart, the convention, the CI that
holds it. The remaining 20 charts follow in their own PRs.
The form, additive and off by default:
httpRoute:
enabled: false # counterpart to ingress.enabled
parentRefs: [] # the Gateway - a platform object
hostnames: [] # empty = [ingress.domain]
Only HTTPRoute with parentRefs is rendered: no Gateway, no gatewayClassName,
no Certificate, and no implementation-specific policy object. That subset is
identical on nginx-gateway-fabric, Cilium, Envoy Gateway and Istio, which is
what lets the implementation be chosen later without touching the charts
again. Class and certificate move to the platform.
Four guards, all against silent failures:
- mutually exclusive with ingress.enabled, with a render abort naming BOTH
value paths. A migration runs over a second hostname, not in parallel.
- parentRefs mandatory in Gateway mode, render abort on the empty list: a
route without a parent is created, is schema-valid, and routes nothing.
- hostnames empty means [ingress.domain], so the hostname has one source.
- the mode is a VALUE, not auto-detection: .Capabilities.APIVersions is
unreliable at template time and a missing CRD fails at install time.
ingress.clusterIssuer was already only read inside the Ingress template, so
the "conditionally required" half of #114 needed no change in this chart -
checked rather than assumed, and it has to be re-checked per chart in the
sweep.
CI, both halves, because neither covers the other:
- the install-test installs cyberchef in GATEWAY mode against the REAL
Gateway-API CRDs (standard channel v1.6.3, pinned and Renovate-tracked,
applied --server-side). A schema-less stub would accept a malformed route
and prove only that something was created. The Ingress path of this one
chart is no longer installed; it is a built-in type that never routed in
k3d anyway, and helm lint renders this chart's defaults - Ingress mode -
on every PR.
- ci/run-httproute-match-test.sh, over every chart on every PR: every
backendRefs entry must name a Service, on a port, that the SAME render
creates, and parentRefs must not be empty. The CRDs accept both of those
mistakes, so the schema cannot catch them, and the only report would be a
route status no controller writes in CI.
What stays unprovable, and is written down instead of implied: that traffic
flows. No Gateway controller runs in k3d.
Minor: additive with unchanged defaults, proven by an empty helm template
diff against origin/main for the default values.
Part of #114
The new httproute-match job (job 2280), over 30 charts: checked: 2 — cyberchef template-chart, not exercised: 28, failed: 0, 4 assertions held. Whole job 13 s including checkout and the Helm setup. Worth noting: paperless-ngx, stalwart and ytdlp-web-player — the three charts with a Helm dependency, which could not be rendered in the authoring environment — rendered without trouble here, so ci/helm-dependencies.sh in the new script does its job.
The Gateway-API CRDs in the install-test (job 2285, ::group::Gateway API CRDs), the part that could not be tried locally at all:
==> Gateway API v1.6.3 (standard channel): https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.6.3/standard-install.yaml
customresourcedefinition.apiextensions.k8s.io/httproutes.gateway.networking.k8s.io serverside-applied
… 10 CRDs + the safe-upgrades ValidatingAdmissionPolicy and its binding, all serverside-applied
customresourcedefinition.apiextensions.k8s.io/httproutes.gateway.networking.k8s.io condition met
==> Gateway API CRDs established.
5.2 s for download, apply and the Established wait. --server-side works as intended — no last-applied-configuration, so the 262144-byte annotation limit the body measures against is not in the path at all.
And the chart went in as an HTTPRoute: helm install succeeded, printed the Gateway-mode branch of NOTES.txt (ACCESS — GATEWAY MODE (httpRoute.enabled: true, ingress.enabled: false)), the deployment rolled out and OK: chart 'cyberchef' installed and all workloads are Ready. Since helm install fails with no matches for kind HTTPRoute when the CRD is absent, a green install here is the evidence that the route was validated against the real schema.
Unchanged by all of this, and still the honest limit: nothing routed. No Gateway controller runs in that cluster, the parentRefs points at a Gateway that does not exist, and the route's status stays empty. Green means "schema-valid object, Ready pod" — not "traffic flows".
## CI is green, and here is what it measured rather than what the body predicted
Run [719](https://git.jk-dev.de/jlab-cluster/helm-charts/actions/runs/719) — all nine checks `success`.
**The new `httproute-match` job** (job 2280), over **30** charts: `checked: 2 — cyberchef template-chart`, `not exercised: 28`, `failed: 0`, **4 assertions held**. Whole job 13 s including checkout and the Helm setup. Worth noting: `paperless-ngx`, `stalwart` and `ytdlp-web-player` — the three charts with a Helm dependency, which could not be rendered in the authoring environment — rendered without trouble here, so `ci/helm-dependencies.sh` in the new script does its job.
**The Gateway-API CRDs in the install-test** (job 2285, `::group::Gateway API CRDs`), the part that could not be tried locally at all:
```
==> Gateway API v1.6.3 (standard channel): https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.6.3/standard-install.yaml
customresourcedefinition.apiextensions.k8s.io/httproutes.gateway.networking.k8s.io serverside-applied
… 10 CRDs + the safe-upgrades ValidatingAdmissionPolicy and its binding, all serverside-applied
customresourcedefinition.apiextensions.k8s.io/httproutes.gateway.networking.k8s.io condition met
==> Gateway API CRDs established.
```
**5.2 s** for download, apply and the `Established` wait. `--server-side` works as intended — no `last-applied-configuration`, so the 262144-byte annotation limit the body measures against is not in the path at all.
**And the chart went in as an HTTPRoute**: `helm install` succeeded, printed the **Gateway-mode** branch of `NOTES.txt` (`ACCESS — GATEWAY MODE (httpRoute.enabled: true, ingress.enabled: false)`), the deployment rolled out and `OK: chart 'cyberchef' installed and all workloads are Ready.` Since `helm install` fails with `no matches for kind HTTPRoute` when the CRD is absent, a green install here *is* the evidence that the route was validated against the real schema.
**Unchanged by all of this, and still the honest limit:** nothing routed. No Gateway controller runs in that cluster, the `parentRefs` points at a Gateway that does not exist, and the route's status stays empty. Green means "schema-valid object, Ready pod" — not "traffic flows".
The authoring environment cannot reach the private Helm registry, so the
three charts with a dependency were missing from the local run and the
number quoted 27 charts. CI run 719 renders all 30 and holds the same 4
assertions - that is the figure a later deviation should be compared
against, so it is the one written down.
jklein
merged commit de92e59bb0 into main2026-10-12 17:35:12 +02:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
jklein
Pilot of #114: the Gateway API as an alternative to the Ingress, in one chart plus the convention and the CI that holds it. The remaining 20 charts are a separate undertaking —
Part of #114, notFixes, because the issue asks for all in-house charts and this delivers one.The form
Only
HTTPRoutewithparentRefsis rendered. No Gateway, nogatewayClassName, no certificate, no implementation-specific policy object (ClientSettingsPolicy,ClientTrafficPolicy). That subset looks identical on nginx-gateway-fabric, Cilium, Envoy Gateway and Istio — which is the whole point: the implementation decision can still fall later without touching the charts again. Class and certificate move to the platform (Gateway listeners,cluster-config).Four guards, each against something that fails without reporting itself:
ingress.enabled, render abort naming both value pathsparentRefsmandatory in Gateway mode, render abort on the empty listhostnamesempty =[ingress.domain].Capabilities.APIVersionsis unreliable at template time, and a missing CRD fails at install timeNOTES.txtnames the active mode and what it costs — including thatingress.annotationshas no counterpart at all, which for this chart is sharper than it sounds: CyberChef has no login, and the chart's own advice so far was "put auth in front of it viaingress.annotations". In Gateway mode that escape hatch does not exist in the chart, and the note says so instead of leaving an open instance behind a sentence that no longer applies.One finding on the plan, reported rather than silently implemented
ingress.clusterIssuer"becomes conditionally required" is a no-op for this chart: both of its reads already sit insidecyberchef.ingress.yaml, behindingress.enabled, andvalues.yamlalready documented that. Nothing was changed for it and nothing needed to be. The sweep has to re-check this per chart rather than inherit the conclusion — README guideline 12, point 1 is about exactly this class of read, andtemplate-chartis the counter-example in the same PR: itsenvblock readsingress.domain, so there the value stays required with the Ingress off.The fixture decision, and what it gives up
ci/cyberchef/test-values.yamlnow installs in Gateway mode. The install-test runs one configuration per chart and the two modes are mutually exclusive, so this is a trade and not a free addition.Given up: the Ingress of this one chart is no longer installed anywhere. That costs little, measurably so — an
Ingressis a built-in GA type the API server has validated for a decade, k3d's own controller is traefik while this chart asks for classnginx, so nothing ever routed through it here either; the install only proved "the API server accepted an Ingress". It keeps being proved by 20 other charts, andhelm lint --strictrenders this chart's defaults — Ingress mode — on every PR.Gained: a real
HTTPRoute, applied against the real Gateway-API CRDs, which is a schema nothing in this repository has ever exercised. That is where a malformedparentRefsorbackendRefsis actually caught.The CRDs: real, pinned, server-side — and not in
ci/common/ci/gateway-api-crds.shfetches the standard channel atv1.6.3(pinned, with a# renovate:comment and a newcustomManagerforci/*.sh) and applies it withkubectl apply --server-side. Called fromci/run-install-test.shonly when the chart's render actually contains anHTTPRoute— detected from the render, so there is no list to maintain and the sweep enrols a chart by switching its fixture.Three decisions worth the review, each with its measurement:
ci/common/'s schema-lessOnePasswordItemCRD is right for its job (nobody is testing the operator's API). For anHTTPRoutethe schema is the job: a stub would accept a malformedparentRefs, a port written as a string, a path type that does not exist — and the install-test would prove only that something was created.--server-side, and not out of taste. Client-side apply stores the whole object inlast-applied-configuration; annotations total at most 262144 bytes; the HTTPRoute CRD of v1.6.3 is 429367 bytes of YAML, 244792 bytes as JSON (measured by re-reading it throughci/yaml2json). That is 93 % of the limit with every release adding fields — client-side happens to fit today and is one upstream release away frommetadata.annotations: Too longon a Renovate PR that has nothing to do with it.ci/common/, which is applied client-side for every chart: putting it there would hand that landmine to all 20-odd charts and spend the download on charts that render no route.It also waits for
condition=Establishedrather than for the object to exist —helm installin that window fails withno matches for kind HTTPRoute, which reads like a missing CRD rather than like a race.The CI assurance, and what its fail path caught
ci/run-httproute-match-test.sh, modelled onci/run-selector-match-test.sh(#96) down to the Helm-as-YAML-parser mechanics, since the runners have neitherpyyamlnoryq. Over every chart on every PR, as the newhttproute-matchjob: everybackendRefsentry must name a Service, on a port, that the same render creates, andparentRefsmust not be empty.The real CRDs do not close either gap — that is why this job exists next to them. The Gateway-API schema accepts an empty
parentRefslist and abackendRefsentry pointing at a Service that was never created. The CRDs prove the object is well-formed; this test proves it points somewhere.The port half is a genuinely new exposure rather than a hypothetical: an Ingress backend references its Service port by name, while
backendRefstakes aPortNumberand cannot — so the number in the route and the port in the Service are kept in step by hand from now on.Anti-vacuum, because this test can be green over nothing (the convention ships
enabled: false): overlays underci/httproute/<chart>.yaml, a chart that has one and renders no route fails, and a run with zero assertions fails.The fail path was driven, not assumed. Six runs in a throwaway copy, each producing a
FAILnaming both sides and exit 1:-service→-svc)references Service 'httproute-cyberchef-svc', which the SAME render does not create … Services this render does create: httproute-cyberchef-service8080, Service serves80references Service … on port 8080, which that Service does not expose (it serves 80)port:line deletedreferences Service … without a port. A backendRef to a Service must carry one — the CRD schema cannot require it conditionallyparentRefs: []with the chart's own guard disabledhas an empty list of parentRefs. A route without a parent attaches to NO Gateway …has an overlay at ci/httproute/cyberchef.yaml but rendered no HTTPRoute, so nothing was checkednot a single HTTPRoute assertion was checked in this run … A pass over zero assertions is not a passMeasured clean: 27 charts, 4 assertions held in ~3 s, no cluster.
What remains unprovable, and is stated instead of implied
That traffic flows. No Gateway controller runs in k3d, so no route is ever reconciled, no status is ever written, nothing routes. What the pipeline does prove: the object is schema-valid (install-test, real CRDs) and the pod becomes Ready, and the route points at a Service and a port the same render creates (render test).
Accepted: Trueis not obtainable here and is claimed nowhere.Verification run locally
helm lint --strict cyberchef/template-chart— 0 failed;helm packageboth.helm templateagainst defaults and against the fixture values, in all three modes (Ingress / Gateway / neither).helm templatediff againstorigin/mainfor the default values — 119 lines each, byte-identical.ci/run-quantity-render-test.sh cyberchef template-chart— both cases exercised the helper, no exponential notation.ci/run-selector-match-test.shon both charts — unchanged (neither renders a selector).ci/run-httproute-match-test.shover all charts, plus the six fail paths above.parentRefs[0]withoutnameis rejected withmissing property 'name'; an unknown key underhttpRoutewithadditional properties 'parentRef' not allowed.parentRefs, no hostname at all. And--set httpRoute=nullstill renders cleanly (null-safe per #99) instead of a nil-pointer abort.NOTES.txtrendered in every branch via the documenteddefine+ scratch-ConfigMap trick, sincehelm templatedoes not renderNOTES.txt.renovate.json5parsed and the newcustomManagerregex matched against the real script (datasource=github-releases,depName=kubernetes-sigs/gateway-api,currentValue=v1.6.3).Not checked here, and named as such: no k3d, no Docker and no Trivy in the authoring environment — so the install-test, the
--server-sideapply and thetrivy configscan are proven by CI only, not locally. The three charts with a Helm dependency could not be rendered locally either (the private registry is unreachable from there — the same limitation the existing selector-match test has), so their legs of the new render test are first exercised by CI. The newcustomManageris not dry-run verified against Renovate; the regex match is tested, the lookup is not.Wiki
Chart-Style-Guide(the convention),CI-CD(the new job and the CRD fixture),cyberchef(the new values and the two modes) andLessons-Learned(a schema-less stub CRD makes an install-test prove nothing — repeatable wherever the next CRD arrives).Part of #114
CI is green, and here is what it measured rather than what the body predicted
Run 719 — all nine checks
success.The new
httproute-matchjob (job 2280), over 30 charts:checked: 2 — cyberchef template-chart,not exercised: 28,failed: 0, 4 assertions held. Whole job 13 s including checkout and the Helm setup. Worth noting:paperless-ngx,stalwartandytdlp-web-player— the three charts with a Helm dependency, which could not be rendered in the authoring environment — rendered without trouble here, soci/helm-dependencies.shin the new script does its job.The Gateway-API CRDs in the install-test (job 2285,
::group::Gateway API CRDs), the part that could not be tried locally at all:5.2 s for download, apply and the
Establishedwait.--server-sideworks as intended — nolast-applied-configuration, so the 262144-byte annotation limit the body measures against is not in the path at all.And the chart went in as an HTTPRoute:
helm installsucceeded, printed the Gateway-mode branch ofNOTES.txt(ACCESS — GATEWAY MODE (httpRoute.enabled: true, ingress.enabled: false)), the deployment rolled out andOK: chart 'cyberchef' installed and all workloads are Ready.Sincehelm installfails withno matches for kind HTTPRoutewhen the CRD is absent, a green install here is the evidence that the route was validated against the real schema.Unchanged by all of this, and still the honest limit: nothing routed. No Gateway controller runs in that cluster, the
parentRefspoints at a Gateway that does not exist, and the route's status stays empty. Green means "schema-valid object, Ready pod" — not "traffic flows".