jklein
7d365c912c
Validate Helm Charts / Detect changed charts (pull_request) Successful in 4s
Validate Helm Charts / Resource quantities (pull_request) Successful in 15s
Validate Helm Charts / Selector match (pull_request) Successful in 15s
Validate Helm Charts / HTTPRoute match (pull_request) Successful in 16s
Validate Helm Charts / Build rss-bridge (pull_request) Successful in 8s
Validate Helm Charts / Trivy config rss-bridge (pull_request) Successful in 23s
Install-test / Install-test rss-bridge (pull_request) Successful in 1m14s
Validate Helm Charts / Install-test (pull_request) Successful in 1m14s
This chart's install-test had failed on the Gitea runner since the move (#51): php-fpm as uid 33 unable to read /app/index.php, the startup probe 403ing through its whole 150s budget, the pod never Ready. The chart was deliberately kept OUT of ci/excluded-charts.txt so that a pass would be noticed rather than silenced. It passed, in this PR. Measured from the run: k3d cluster up, helm install in Ingress mode, pod 1/1 Ready in 22s with 0 restarts, no "Permission denied" anywhere in the job, and all eight check contexts green. The chart is ruled out as the cause by a diff rather than by an argument: the rendered output for the fixture values is BYTE-IDENTICAL to origin/main - proven in the previous commit to justify the Minor bump - so the pod spec that succeeded is, line for line, the pod spec that had been failing. The implicated layer is the runner, which is where #51 had already placed the burden of proof. The control case arrived for free, from evidence collected for an unrelated reason. What this does NOT establish, and the docs say so: that it is repaired. It is one run, nobody has identified what changed on the runner, and an intermittent effect needs several runs per side. #51 therefore stays open and is to be closed on a cause, not on a colour - which was the standing instruction there before the green arrived. Corrected accordingly, because shipping documentation that says the test fails while it demonstrably passed is the half-finished state this repo tries not to leave behind: - README: the httproute-test paragraph, guideline 4's closing passage on the last chart of the sweep, and the chart table row. - rss-bridge/templates/NOTES.txt: the Gateway branch no longer claims the chart has no successful install-test. What remains true, and is what it now says, is that the install-test installs the INGRESS mode, so the Gateway mode is render-only - the same position as all 21 other charts of the sweep rather than a worse one. - ci/httproute/rss-bridge.yaml: same correction, plus why the overlay stays load-bearing either way. The wiki carries the same correction in the same round (rss-bridge, CI-CD) plus a Lessons-Learned entry on the decision that produced the signal: an excluded test is not a quiet test but a blind one, because you also lose the moment the fault stops existing.
70 lines
3.8 KiB
YAML
70 lines
3.8 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/rss-bridge/test-values.yaml, and for this
|
|
# chart the reason is sharper than for its siblings. The install-test runs
|
|
# exactly ONE configuration per chart and the two modes are mutually exclusive,
|
|
# so switching the fixture would trade this chart's Ingress away - and that
|
|
# fixture's Ingress is the only thing that exercises rss-bridge.tlsGroups, the
|
|
# secret-grouping helper that keeps the three grown certificates of the real
|
|
# installation on their existing names. That helper is inert in Gateway mode
|
|
# (nothing to group once TLS sits on the listener), so a fixture switched to
|
|
# this mode would stop covering it entirely. The CRD schema check the pilot
|
|
# paid for is already performed by cyberchef's fixture against the real
|
|
# Gateway-API CRDs; what is missing without this file is the render-level
|
|
# assurance, and that is what this overlay buys.
|
|
#
|
|
# A note on this chart's install-test, because it has a history. It had failed
|
|
# on the Gitea runner since the move - php-fpm unable to read /app/index.php,
|
|
# the startup probe 403ing through its whole budget, the pod never Ready (Gitea
|
|
# #51), reproduced on two images while the same chart and image ran healthy in
|
|
# the cluster. The chart was deliberately kept OUT of ci/excluded-charts.txt so
|
|
# that a pass would be noticed rather than silenced, and in the PR that added
|
|
# this overlay it PASSED: pod 1/1 Ready in 22s, 0 restarts, no permission error
|
|
# in the job. Since that PR's rendered defaults are byte-identical to
|
|
# origin/main, the chart is ruled out as the cause and the runner is the
|
|
# implicated layer - which is where #51 had already placed it. One run is not
|
|
# proof of permanence, so #51 is not closed on the strength of a colour.
|
|
#
|
|
# Either way this overlay stays load-bearing: the install-test installs the
|
|
# INGRESS mode (that is what the fixture sets), so the Gateway mode of this
|
|
# chart is covered here at render level and nowhere else - the same situation
|
|
# as every other chart in the sweep.
|
|
#
|
|
# ingress.enabled: false is not optional here - the chart ships it as TRUE and
|
|
# aborts its own render when both modes are on.
|
|
#
|
|
# httpRoute.hostnames MUST be supplied, and this overlay is the second in the
|
|
# repository that has to (homeassistant's was the first). The other charts let
|
|
# an empty hostnames list fall back to ingress.domain; this chart has no
|
|
# ingress.domain, and it deliberately does not reuse ingress.hosts from the
|
|
# fixture, because those entries carry tlsSecretName values that address
|
|
# nothing once the certificate sits on the Gateway's listener. The render
|
|
# aborts on an empty list rather than publishing a route that matches every
|
|
# request reaching its listener.
|
|
#
|
|
# THREE hostnames on ONE object, which is the shape this chart's production
|
|
# installation has (three hosts, all serving the same Service at "/"). It is
|
|
# also the shape the test should see: one HTTPRoute, one rule, one backendRef,
|
|
# several hostnames - as opposed to homeassistant's one-object-per-host or
|
|
# matrix-synapse's two objects with different paths and backends. The three
|
|
# names are kept recognisably parallel to ci/rss-bridge/test-values.yaml so the
|
|
# two modes can be read side by side, but they are NOT the same values: these
|
|
# are the route's hostnames, and the fixture's are the Ingress's hosts.
|
|
ingress:
|
|
enabled: false
|
|
httpRoute:
|
|
enabled: true
|
|
parentRefs:
|
|
- name: public
|
|
namespace: gateway
|
|
sectionName: https
|
|
hostnames:
|
|
- rss-bridge.ci.local
|
|
- rssbridge.ci.local
|
|
- rss-bridge.ci.example
|