Gateway API as the second routing mode (pilot on cyberchef)
Documents Gitea #114's pilot, which is in helm-charts PR #115.
Chart-Style-Guide §4 becomes "Ingress and Gateway API" and carries the
binding form: HTTPRoute with parentRefs only - no Gateway, no
gatewayClassName, no certificate, no implementation-specific policy object,
because that subset is identical on nginx-gateway-fabric, Cilium, Envoy
Gateway and Istio. Plus the four guards (a value instead of auto-detection,
mutual exclusion with ingress.enabled, mandatory parentRefs, one source of
truth for the hostname) and what has no counterpart at all: proxy-body-size
and auth annotations. The §4 anchor changed, so the reference on the
homeassistant page moved with it.
CI-CD gains the httproute-match job as #5 (install-test renumbered to #7)
and a section on the Gateway-API CRD fixture - why it is real rather than a
stub, why --server-side (the CRD is 244792 bytes as JSON against a 262144
byte annotation limit), and why it is not in ci/common/.
cyberchef gains the httpRoute values, a "Routing modes" section, the
attachment check, and the honest version of its CI section: its install-test
now runs in Gateway mode, which gives up installing the Ingress and buys a
route validated against a real schema. What stays unprovable is named -
nothing routes in k3d.
template-chart carries the reference implementation; New-Chart gains the
overlay obligation; Renovate replaces the blanket "ci/** is not managed"
with the distinction that was always meant - a fixture image stays
unmanaged, a pinned tool is tracked wherever it lives.
Lessons-Learned: the stub CRD that would have proved nothing.
CI/CD: publish-helm-chart liegt jetzt in workflow-util/pipelines
Die Seite beschrieb den Publish-Workflow als Workflow dieses Repositories. Er
liegt seit Gitea #66 in workflow-util/pipelines und wird an einen Tag gebunden
aufgerufen.
Neu ist ein Abschnitt, was ein Aufrufer hier beisteuert: registry-owner als
Pflichteingabe mit github.repository_owner, secrets: inherit, die
Repository-Variable OP_CONNECT_HOST, und ci/helm-dependencies.sh - das bleibt
unser Skript und laeuft aus unserem Checkout, womit es Teil des Vertrags ueber
die Repository-Grenze wird.
Die Begruendungen des Upload-Schritts stehen nicht mehr hier, sondern im Wiki
von pipelines, mit Verweis. Zwei Kopien einer Erklaerung heisst, dass eine von
beiden irgendwann falsch ist - und die Datei, die diese Saetze beschreiben, ist
nicht mehr unsere. Was hier bleibt, ist das Repository-Eigene: die erwartete
Form des Tresor-Felds, der zweite Eigentuemer auf derselben Instanz, der
Spiegel ohne Actions und der erneute Upload derselben Version.
Der Abschnitt zum Nachweis ist umgeschrieben: Ein manueller Dispatch einer
Huelle ist nach dem Umzug der einzige Weg, einen Publish von Hand zu starten,
und er ist das Einzige, was die drei offenen Punkte beweisen kann -
cross-repo-uses, eine Variable in einem fremd aufgerufenen Workflow, und der
Upload selbst.
Dazu nachgezogen: die Huellenzahl (25, nicht 26 oder 24), der Hinweis bei
helm-dependencies.sh, und in New-Chart der Schritt 1 - eine Huelle wird kopiert
und nicht aus dem Gedaechtnis geschrieben, weil eine fehlende Owner-Eingabe
erst beim echten Publish auffaellt.
One page per chart - prerequisites, installation walkthrough, the required
1Password fields, the complete values reference and the chart's operating
traps - plus the long form of the workflow, the forge and its measured
differences, the pipelines, versioning, Renovate, the chart style guide, the
procedure for a new chart, local development, and the incidents each rule was
bought with.
Chart pages quote versions as snapshots; Chart.yaml stays authoritative,
because Renovate moves app versions continuously and never edits the wiki.