jklein
50f683776e
Validate Helm Charts / Detect changed charts (pull_request) Successful in 4s
Validate Helm Charts / Resource quantities (pull_request) Successful in 14s
Validate Helm Charts / HTTPRoute match (pull_request) Successful in 13s
Validate Helm Charts / Build cyberchef (pull_request) Successful in 6s
Validate Helm Charts / Trivy config cyberchef (pull_request) Successful in 18s
Validate Helm Charts / Build template-chart (pull_request) Successful in 7s
Validate Helm Charts / Trivy config template-chart (pull_request) Successful in 17s
Install-test / Install-test cyberchef (pull_request) Successful in 1m0s
Validate Helm Charts / Install-test (pull_request) Successful in 1m0s
Validate Helm Charts / Selector match (pull_request) Successful in 12s
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
41 lines
2.0 KiB
YAML
41 lines
2.0 KiB
YAML
# 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
|