jklein
f530f58b1d
Validate Helm Charts / Resource quantities (pull_request) Successful in 15s
Validate Helm Charts / Selector match (pull_request) Successful in 14s
Validate Helm Charts / HTTPRoute match (pull_request) Successful in 14s
Validate Helm Charts / Detect changed charts (pull_request) Successful in 4s
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 1m6s
Validate Helm Charts / Install-test (pull_request) Successful in 1m6s
Publish Helm Chart with patched Application Version / publish-helm-chart (push) Successful in 12s
Publish RSS-Bridge Helm Chart / Publish RSS-Bridge Helm Chart (push) Successful in 12s
SonarQube Analysis / SonarQube Analysis (push) Successful in 45s
PR #124 merged at 12:25 and the maintainer closed #51 one second later, on the strength of that round's green install-test. Three statements that merged with #124 are stale as a result, and they are stale in the direction that matters - they describe a failing test and an open issue: - rss-bridge/templates/rss-bridge.httproute.yaml and values.yaml said the install-test "fails on the Gitea runner (#51)", in the present tense, and values.yaml added "and that test is still red". - ci/httproute/rss-bridge.yaml said "#51 is not closed on the strength of a colour", which was true when written and is now the opposite of what happened. Replaced with what is actually known, and the emphasis moved to the part that outlives the colour: the test went green on a render byte-identical to main, which rules the chart out and leaves the runner - and THE CAUSE WAS NEVER IDENTIFIED. The diagnostic programme in #51 (docker info for userns and the dind configuration, the same image in a local k3d without remapping) was not executed. So a recurrence is a fresh finding rather than a known quirk, and the overlay comment now says so where whoever sees the red will be reading. Also carries the wording change that was already on this branch when #124 merged: the reproduced green is phrased as "every run of that branch since" rather than pinned to a count, because each commit recording the count invalidated it - a third green arrived with the push after "two". Patch bump, per the rule #40 was argued on: a comment in a chart directory is still a change to that chart, so it is a patch plus a publish. No template output changes - the render for the fixture values is byte-identical to the pre-#124 main, which the tests re-confirm.
76 lines
4.3 KiB
YAML
76 lines
4.3 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
|
|
# on every run of that branch since, so it is not a fluke, and #51 was closed
|
|
# on that round. What was NEVER identified is the cause: nobody established
|
|
# what changed on the runner, and the diagnostic programme in that issue
|
|
# (docker info for userns and the dind configuration, the same image in a
|
|
# local k3d without remapping) was not executed. So if this chart's
|
|
# install-test goes red again, that is a fresh finding and not a known quirk -
|
|
# and this comment is the context it should be read against.
|
|
#
|
|
# 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
|