2026-10-13 12:36:59 +02:00
5 changed files with 19 additions and 9 deletions
@@ -183,7 +183,7 @@ Three things to know before touching it:

 Measured in CI (run 719, the pilot): **30 charts, 4 assertions held**, whole job 13 s including checkout and the Helm setup, no cluster. Group 1 took that to 20 assertions over 10 charts and group 2 to 36 over 15; the prefix/redirect pairing of Gitea #118 adds the first check since the pilot rather than a chart, which brought it to 37 over 15 — one assertion for `freesailarr`'s `/qbittorrent`, plus one more "not checked" line for the backend-less redirect rule it demands. Group 3 took it to `56` assertions over `21` charts, from six charts of which three contribute more than one route: `keycloak` 4 (public and admin routes), `matrix-synapse` 4 (homeserver and delegation routes), `homeassistant` 5 (two routes, three rules — its overlay was the first in the repo that has to *supply* hostnames, since the chart has no `ingress.domain`), `bulwark` 2, `stalwart` 2, `ytdlp-web-player` 2. **`rss-bridge` finishes the sweep at `58` assertions over `22` charts** — read on this branch, which does **not** contain the realm-hostname round of Gitea #122 (measured separately at `60` over `21`, on a branch that did not contain `rss-bridge`). **Neither total includes the other, so the figure to trust from either is the delta**; the running total is whatever the first run on `main` prints once both have landed, and it should be read there rather than added up by hand. The delta here is one route, so two assertions, and its overlay is the **second** that has to supply hostnames — for a different reason than `homeassistant`'s, which is worth keeping apart. `homeassistant` has no `httpRoute.hostnames` key at all and its overlay supplies the names through `ingress.hosts`; `rss-bridge` *has* the key and its overlay fills it, because this chart has no `ingress.domain` to fall back to either but its hostnames are unambiguous (one Service, one path).

-**And in the same PR that chart's install-test went green, which is the event Gitea #51 was waiting for.** It had failed on the Gitea runner for months (uid 33 unable to read `/app/index.php`, startup probe 403 through its whole budget), and the chart was deliberately kept *out* of `ci/excluded-charts.txt` precisely so that the day it passed would be noticed rather than silenced. It passed: k3d cluster up, `helm install` in Ingress mode, pod `1/1 Ready` in 22 s with 0 restarts, and no `Permission denied` anywhere in the job. **The chart cannot be the reason, and that is measured rather than argued** — the rendered output for the fixture values is byte-identical to `origin/main`, so the pod spec that installed is exactly the one `main` produces. The implicated layer is the runner, which is where #51 had already put the burden of proof. Two cautions belong with the result: **nobody has identified what changed on the runner**, and a green test does not explain itself — it reproduced across two consecutive runs on two different commits of that PR, which is two data points rather than one, but still no cause; and the install covers **Ingress** mode, since that is what the fixture installs — so this chart's Gateway mode stays render-only, exactly like its 21 siblings rather than worse than them.
+**And in the same PR that chart's install-test went green, which is the event Gitea #51 was waiting for.** It had failed on the Gitea runner for months (uid 33 unable to read `/app/index.php`, startup probe 403 through its whole budget), and the chart was deliberately kept *out* of `ci/excluded-charts.txt` precisely so that the day it passed would be noticed rather than silenced. It passed: k3d cluster up, `helm install` in Ingress mode, pod `1/1 Ready` in 22 s with 0 restarts, and no `Permission denied` anywhere in the job. **The chart cannot be the reason, and that is measured rather than argued** — the rendered output for the fixture values is byte-identical to `origin/main`, so the pod spec that installed is exactly the one `main` produces. The implicated layer is the runner, which is where #51 had already put the burden of proof. Two cautions belong with the result: **nobody has identified what changed on the runner**, and a green test does not explain itself — it has reproduced on every run of that branch since, across several commits, so it is not a fluke - but that is still a colour and not a cause; and the install covers **Ingress** mode, since that is what the fixture installs — so this chart's Gateway mode stays render-only, exactly like its 21 siblings rather than worse than them.

 The fail path was exercised rather than assumed: a Service renamed in the route, a port the Service does not expose, a port left out entirely, an emptied `parentRefs` with the chart's own guard disabled, an overlay that renders no route, a run with zero assertions, and — for the pairing — both the redirect rule deleted outright and the redirect pointed at a path other than the one stripped; each produced a `FAIL` naming both sides and a non-zero exit.

@@ -28,8 +28,13 @@
 # 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.
+# 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
@@ -5,7 +5,7 @@ icon: https://raw.githubusercontent.com/RSS-Bridge/rss-bridge/master/static/logo

 type: application

-version: 2.1.0+up2026.09.30
+version: 2.1.1+up2026.09.30
 appVersion: "2026-09-30"

 maintainers:
@@ -2,8 +2,11 @@
 The Gateway-API alternative to rss-bridge.ingress.yaml (Gitea #114), and the
 LAST chart of that sweep: 22 charts carried an Ingress template and 21 an
 HTTPRoute template, and the difference was this one. It was held back because
-its install-test fails on the Gitea runner (#51), not for anything about its
-shape.
+its install-test had been failing on the Gitea runner (#51), not for anything
+about its shape - and that test went green in the very PR that converted it,
+on a render byte-identical to main, which is what ruled the chart out and left
+the runner. #51 was closed on the strength of that round; the cause was never
+identified, so a recurrence is a fresh finding rather than a known quirk.

 WHAT THIS RENDERS, AND WHAT IT DELIBERATELY DOES NOT

@@ -272,9 +272,11 @@ ingress:
 # THE GATEWAY-API ALTERNATIVE TO THE INGRESS ABOVE (Gitea #114), and this chart
 # is the LAST of that sweep - 22 charts carried an Ingress template, 21 an
 # HTTPRoute template, and the difference was this one. It was held back because
-# its install-test fails on the Gitea runner (#51), not for anything about its
-# shape, and that test is still red: the failure is a known, bounded
-# environment defect and no finding about this mode.
+# its install-test had been failing on the Gitea runner (#51), not for anything
+# about its shape - and that test went green in the very PR that converted it,
+# on a render byte-identical to main, which ruled the chart out and left the
+# runner. #51 was closed on that round; the cause was never identified, so a
+# recurrence is a fresh finding rather than a known quirk.
 #
 # Off by default, so an existing release is unaffected. Mutually exclusive with
 # ingress.enabled - the render aborts when both are true, naming both value