jklein
23ac537e24
Validate Helm Charts / Detect changed charts (pull_request) Successful in 7s
Validate Helm Charts / Resource quantities (pull_request) Successful in 19s
Validate Helm Charts / Selector match (pull_request) Successful in 16s
Validate Helm Charts / HTTPRoute match (pull_request) Successful in 17s
Validate Helm Charts / Build rss-bridge (pull_request) Successful in 9s
Validate Helm Charts / Trivy config rss-bridge (pull_request) Successful in 20s
Install-test / Install-test rss-bridge (pull_request) Successful in 1m8s
Validate Helm Charts / Install-test (pull_request) Successful in 1m8s
The previous commit recorded the install-test going green and hedged it with "it is one run". Pushing that commit produced a second run, on a second commit, and it was green too - run 792 job 2623 (1m10s) and run 794 job 2638 (1m14s), both with the chart genuinely in the matrix. So the hedge was understated in one direction and the real caution lies elsewhere. Corrected to say what is actually true: it reproduced over two consecutive runs, so it is not a fluke - and nobody has identified what changed on the runner, which is the reason #51 stays open. A green test does not explain itself, and the diagnostic programme in that issue's body (docker info on the runner for userns and the dind configuration, the same image in a local k3d without remapping) remains unexecuted. "Close an issue on a cause, not on a colour" is unaffected by the count.
71 lines
3.9 KiB
YAML
71 lines
3.9 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. It reproduced
|
|
# over two consecutive runs, but nobody has identified what changed there, 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
|