jlab-cluster/helm-charts
3
0 Fork 0
Code Issues 15 Pull Requests 3 Actions Packages Wiki Activity

rss-bridge: Install-Test scheitert auf dem Gitea-Runner (uid 33 kann /app/index.php nicht lesen) #51

New Issue
Closed
opened 2026-09-27 12:04:13 +02:00 by jlab-bot · 7 comments
jlab-bot commented 2026-09-27 12:04:13 +02:00
Member
Copy link
Copy source

Der Install-Test von rss-bridge scheitert auf dem Gitea-Runner. php-fpm läuft als uid 33 und kann /app/index.php nicht lesen:

ERROR: Unable to open primary script: /app/index.php (Permission denied)
GET /?action=health HTTP/1.1" 403

Die Startup-Probe bekommt über ihr gesamtes Budget von 150s eine 403, der Pod wird nie Ready. Dazu im selben Protokoll: libcurl-impersonate.so lässt sich nicht per LD_PRELOAD laden — dasselbe Muster.

Aufgefallen ist es in PR #48 (Issue #40), der nur einen Kommentar im Chart ändert.

Was gemessen ist, und was daraus folgt

Drei Feststellungen, die gleichzeitig zutreffen:

  1. Das Chart rendert byte-identisch zu main. Belegt im PR: Der installierte Pod-Spec ist der, den main heute erzeugt.

  2. Das Image ist unverändert. Anonym gegen die Registry geprüft:

    • rssbridge/rss-bridge:2025-08-05 → sha256:569f01f3…, erstellt 2025-08-05T17:53:25Z
    • rssbridge/rss-bridge:latest → sha256:60689611…, erstellt 2026-08-28T16:50:42Z

    Der gezogene Digest trägt genau das Datum seines Tags. Die zunächst naheliegende Vermutung, das Datums-Tag sei neu gepusht worden, ist damit widerlegt.

  3. rss-bridge wurde zuletzt am 2026-08-29 geändert (e666cfe), also vor dem Umzug auf Gitea. Weil der Install-Test nur geänderte Charts erfasst, ist der Lauf in #48 der erste dieses Charts auf dem Gitea-Runner.

Gleiches Chart, gleiches Image, anderes Ergebnis: Der Unterschied liegt in der Umgebung.

Hypothese, ausdrücklich unvermessen

Die README nennt unter „What a GitHub runner had been providing quietly" zwei Dinge als nicht gemessen: /dev/fuse und User-Namespaces. Ein dind-Runner mit userns-remap verschiebt die Eigentümerschaft der Image-Dateien aus Sicht des Containers — und genau so sieht das Symptom aus: uid 33 kommt weder an /app/index.php noch an die .so.

Das ist eine Hypothese. Zu prüfen ist sie am Runner, nicht am Chart:

  • docker info auf dem Runner: userns und die dind-Konfiguration.
  • Dieselbe Image-Version in einem lokalen k3d ohne Remapping installieren. Kommt der Pod dort hoch, ist die Sache am Runner entschieden.
  • Falls er auch dort scheitert: die Eigentümerschaft im Image selbst prüfen (/app, index.php) und die Behauptung in rss-bridge/values.yaml Zeile 43 gegen den Befund stellen — sie steht dort als gemessene Tatsache.

Was offen ist und nicht behauptet werden darf

Ob die laufende Installation betroffen ist, ist unbekannt. Wenn die Ursache am Runner liegt, läuft die Produktion unberührt weiter; liegt sie im Chart oder im Image, ist auch dort etwas kaputt. Beides ist derzeit nicht belegt — und ein Blick in den Cluster ist der billigste Weg, es zu entscheiden.

Umfang

  • Ursache feststellen, in der oben genannten Reihenfolge.
  • Je nach Befund: Runner richten (gehört nach cluster-config) oder das Chart anpassen, dann mit Versionsschritt, Wiki-Runde und neu gemessenen Angaben in values.yaml.
  • Die Kommentar-Korrektur aus #40 hier mitnehmen. rss-bridge wurde aus #48 herausgenommen, damit die übrigen 21 Charts mergen können; #40 bleibt offen, bis dieses Chart nachgezogen ist. Der Chart wird hier ohnehin angefasst, also kostet es nichts extra.

Verwandt

Der Befund ist größer als dieses Chart — siehe das Issue zur Install-Test-Abdeckung nach dem Umzug: Für jedes seit dem Umzug nicht angefasste Chart stammt der letzte grüne Install-Test aus einer anderen Umgebung.

Der Install-Test von `rss-bridge` scheitert auf dem Gitea-Runner. php-fpm läuft als uid 33 und kann `/app/index.php` nicht lesen: ``` ERROR: Unable to open primary script: /app/index.php (Permission denied) GET /?action=health HTTP/1.1" 403 ``` Die Startup-Probe bekommt über ihr gesamtes Budget von 150s eine 403, der Pod wird nie Ready. Dazu im selben Protokoll: `libcurl-impersonate.so` lässt sich nicht per `LD_PRELOAD` laden — dasselbe Muster. Aufgefallen ist es in PR #48 (Issue #40), der nur einen Kommentar im Chart ändert. ## Was gemessen ist, und was daraus folgt Drei Feststellungen, die gleichzeitig zutreffen: 1. **Das Chart rendert byte-identisch zu `main`.** Belegt im PR: Der installierte Pod-Spec ist der, den `main` heute erzeugt. 2. **Das Image ist unverändert.** Anonym gegen die Registry geprüft: - `rssbridge/rss-bridge:2025-08-05` → `sha256:569f01f3…`, erstellt **2025-08-05T17:53:25Z** - `rssbridge/rss-bridge:latest` → `sha256:60689611…`, erstellt 2026-08-28T16:50:42Z Der gezogene Digest trägt genau das Datum seines Tags. Die zunächst naheliegende Vermutung, das Datums-Tag sei neu gepusht worden, ist damit **widerlegt**. 3. **`rss-bridge` wurde zuletzt am 2026-08-29 geändert** (`e666cfe`), also **vor** dem Umzug auf Gitea. Weil der Install-Test nur geänderte Charts erfasst, ist der Lauf in #48 **der erste dieses Charts auf dem Gitea-Runner**. Gleiches Chart, gleiches Image, anderes Ergebnis: Der Unterschied liegt in der Umgebung. ## Hypothese, ausdrücklich unvermessen Die README nennt unter „What a GitHub runner had been providing quietly" zwei Dinge als **nicht gemessen**: `/dev/fuse` und **User-Namespaces**. Ein dind-Runner mit `userns-remap` verschiebt die Eigentümerschaft der Image-Dateien aus Sicht des Containers — und genau so sieht das Symptom aus: uid 33 kommt weder an `/app/index.php` noch an die `.so`. Das ist eine Hypothese. Zu prüfen ist sie **am Runner**, nicht am Chart: - `docker info` auf dem Runner: `userns` und die dind-Konfiguration. - Dieselbe Image-Version in einem lokalen k3d ohne Remapping installieren. Kommt der Pod dort hoch, ist die Sache am Runner entschieden. - Falls er auch dort scheitert: die Eigentümerschaft im Image selbst prüfen (`/app`, `index.php`) und die Behauptung in `rss-bridge/values.yaml` Zeile 43 gegen den Befund stellen — sie steht dort als gemessene Tatsache. ## Was offen ist und nicht behauptet werden darf **Ob die laufende Installation betroffen ist, ist unbekannt.** Wenn die Ursache am Runner liegt, läuft die Produktion unberührt weiter; liegt sie im Chart oder im Image, ist auch dort etwas kaputt. Beides ist derzeit nicht belegt — und ein Blick in den Cluster ist der billigste Weg, es zu entscheiden. ## Umfang - Ursache feststellen, in der oben genannten Reihenfolge. - Je nach Befund: Runner richten (gehört nach `cluster-config`) **oder** das Chart anpassen, dann mit Versionsschritt, Wiki-Runde und neu gemessenen Angaben in `values.yaml`. - **Die Kommentar-Korrektur aus #40 hier mitnehmen.** `rss-bridge` wurde aus #48 herausgenommen, damit die übrigen 21 Charts mergen können; #40 bleibt offen, bis dieses Chart nachgezogen ist. Der Chart wird hier ohnehin angefasst, also kostet es nichts extra. ## Verwandt Der Befund ist größer als dieses Chart — siehe das Issue zur Install-Test-Abdeckung nach dem Umzug: Für jedes seit dem Umzug nicht angefasste Chart stammt der letzte grüne Install-Test aus einer anderen Umgebung.
jlab-bot commented 2026-09-27 16:07:05 +02:00
Author
Member
Copy link
Copy source

Stand vom Betreuer (2026-09-27): Die laufende Instanz von rss-bridge ist gesund. Damit ist die offene Frage aus dem Issue-Text beantwortet, und zwar in die günstige Richtung.

Was das bedeutet:

  • Kein Ausfall. Der rote Install-Test ist ein Problem der Prüfumgebung, nicht der Produktion. Die Dringlichkeit sinkt entsprechend.
  • Die Hypothese wird dadurch stärker, nicht schwächer. Gleiches Chart, gleiches Abbild, gesund im Cluster, gescheitert auf dem Runner — das schließt Abbild und Chart als Ursache praktisch aus und lässt die Umgebung übrig.
  • Die Behauptung in rss-bridge/values.yaml Zeile 43 („/app und jede Datei darin gehört www-data im Abbild") steht damit unbeschädigt da. Sie ist im Cluster offenbar zutreffend; reproduzierbar ist sie auf dem Runner nicht.

Nächster Schritt bleibt derselbe und ist der billigste: docker info auf dem Runner, mit Blick auf userns und die dind-Konfiguration. Fällt dort ein Remapping auf, ist die Sache entschieden und der Eingriff gehört auf die Knoten-Seite (cluster-config), nicht ins Chart.

Was hier nicht getan werden sollte, solange das offen ist: die Härtung des Charts aufweichen, damit der Test grün wird. Das Chart läuft in Produktion genau so.

Stand vom Betreuer (2026-09-27): **Die laufende Instanz von rss-bridge ist gesund.** Damit ist die offene Frage aus dem Issue-Text beantwortet, und zwar in die günstige Richtung. Was das bedeutet: - **Kein Ausfall.** Der rote Install-Test ist ein Problem der Prüfumgebung, nicht der Produktion. Die Dringlichkeit sinkt entsprechend. - **Die Hypothese wird dadurch stärker, nicht schwächer.** Gleiches Chart, gleiches Abbild, gesund im Cluster, gescheitert auf dem Runner — das schließt Abbild und Chart als Ursache praktisch aus und lässt die Umgebung übrig. - **Die Behauptung in `rss-bridge/values.yaml` Zeile 43** („/app und jede Datei darin gehört www-data im Abbild") steht damit unbeschädigt da. Sie ist im Cluster offenbar zutreffend; reproduzierbar ist sie auf dem Runner nicht. Nächster Schritt bleibt derselbe und ist der billigste: `docker info` auf dem Runner, mit Blick auf `userns` und die dind-Konfiguration. Fällt dort ein Remapping auf, ist die Sache entschieden und der Eingriff gehört auf die Knoten-Seite (`cluster-config`), nicht ins Chart. Was hier **nicht** getan werden sollte, solange das offen ist: die Härtung des Charts aufweichen, damit der Test grün wird. Das Chart läuft in Produktion genau so.
jlab-bot commented 2026-09-27 23:07:56 +02:00
Author
Member
Copy link
Copy source

Zwei neue Messungen aus dem Rundumtest (Lauf 240, alle 24 Charts, 19 Minuten) und aus dem Abbild selbst. Sie widerlegen beide bisherigen Erklärungen, meine eingeschlossen.

1. Der Runner zieht dasselbe Abbild

Aus der Pod-Beschreibung im Protokoll:

Image:     docker.io/rssbridge/rss-bridge:2025-08-05
Image ID:  docker.io/rssbridge/rss-bridge@sha256:569f01f3faecd0d34d702e01b34eb0a769f7bedb84caf6dff29821d18b46f971

Genau der Digest, der auf Docker Hub hinter dem Tag steht und dessen Erstellungszeitpunkt zum Tag-Datum passt. Die Abbild-Hypothese ist damit endgültig erledigt, nicht nur unwahrscheinlich.

Nebenbei: Gemountet werden nur /app/cache (emptyDir) und /app/whitelist.txt (ConfigMap, subPath). Nichts liegt über /app selbst.

2. Die Eigentümerschaft kann es nicht sein

Aus den Layern des Abbilds gelesen (Layer 6, amd64):

/app            uid=33 gid=33 mode=0755
/app/index.php  uid=33 gid=33 mode=0644

0644 heißt für alle lesbar, in einem Verzeichnis mit 0755, also für alle betretbar. Ein „Permission denied" auf diese Datei ist damit kein Rechte-Problem im üblichen Sinn: Jede uid dürfte sie lesen, auch eine, die durch ein userns-Mapping verschoben wurde.

Damit fällt auch meine eigene userns-Hypothese. Sie hätte erklärt, warum uid 33 an eine www-data-Datei nicht herankommt — aber die Datei ist für alle lesbar, also gibt es nichts zu verschieben. Der Satz in rss-bridge/values.yaml Zeile 43 („uid/gid 33 ist nicht austauschbar, weil /app www-data gehört") beschreibt die Eigentümerschaft korrekt, ist für diesen Fehler aber ohne Bedeutung.

3. Was der Rundumtest zusätzlich sagt

23 von 24 Charts sind hochgekommen, nur rss-bridge nicht. Fast alle laufen non-root mit readOnlyRootFilesystem. Ein Effekt, der non-root-Prozessen grundsätzlich den Zugriff auf Abbild-Dateien verwehrt, hätte weit mehr als ein Chart getroffen. Das schwächt jede Erklärung, die allein am Runner hängt.

Was übrig bleibt

Kandidaten, die einen Zugriff unabhängig vom Modus verweigern:

  • eine FUSE- oder Overlay-Einhängung, die für den Prozess nicht zugänglich ist (passt zu der zweiten Meldung im Protokoll: libcurl-impersonate.so lässt sich nicht per LD_PRELOAD laden — dasselbe Muster, „non-root kommt an Abbild-Dateien nicht heran"),
  • eine LSM-Ablehnung (AppArmor, SELinux),
  • etwas PHP-Eigenes: php-fpm meldet diesen Text auch, wenn der von nginx übergebene SCRIPT_FILENAME für den Worker nicht auflösbar ist — nicht nur bei fehlenden Leserechten.

Der Widerspruch zwischen „trifft nur ein Chart" und „sieht nach einem allgemeinen Dateisystem-Effekt aus" ist ungelöst und genau die Stelle, an der weitergesucht werden muss.

Nächste Schritte, jetzt billig

Seit #54 gemergt ist, braucht eine Messung keinen Chart-PR mehr:

  1. Einen Zweig mit einem zusätzlichen Diagnose-Schritt anlegen (ls -ln /app, id, stat /app/index.php, mount | grep overlay im laufenden Pod) und den Rundumtest auf diesem Zweig mit charts: rss-bridge auslösen — tea actions workflows dispatch --ref <zweig> erlaubt das. Kein Versionsschritt, keine Veröffentlichung.
  2. Parallel weiterhin docker info auf dem Runner, vor allem Storage-Driver und userns — jetzt nicht mehr als Haupt-, sondern als Nebenverdacht.

Auslösen kann ich es nicht: Das Bot-Konto hat kein Schreibrecht am Repository, dispatch scheitert mit „user should have a permission to write to a repo". Das muss der Betreuer tun.

Zwei neue Messungen aus dem Rundumtest (Lauf 240, alle 24 Charts, 19 Minuten) und aus dem Abbild selbst. **Sie widerlegen beide bisherigen Erklärungen, meine eingeschlossen.** ## 1. Der Runner zieht dasselbe Abbild Aus der Pod-Beschreibung im Protokoll: ``` Image: docker.io/rssbridge/rss-bridge:2025-08-05 Image ID: docker.io/rssbridge/rss-bridge@sha256:569f01f3faecd0d34d702e01b34eb0a769f7bedb84caf6dff29821d18b46f971 ``` Genau der Digest, der auf Docker Hub hinter dem Tag steht und dessen Erstellungszeitpunkt zum Tag-Datum passt. Die Abbild-Hypothese ist damit endgültig erledigt, nicht nur unwahrscheinlich. Nebenbei: Gemountet werden nur `/app/cache` (emptyDir) und `/app/whitelist.txt` (ConfigMap, subPath). **Nichts liegt über `/app` selbst.** ## 2. Die Eigentümerschaft kann es nicht sein Aus den Layern des Abbilds gelesen (Layer 6, amd64): ``` /app uid=33 gid=33 mode=0755 /app/index.php uid=33 gid=33 mode=0644 ``` `0644` heißt **für alle lesbar**, in einem Verzeichnis mit `0755`, also für alle betretbar. Ein „Permission denied" auf diese Datei ist damit **kein Rechte-Problem im üblichen Sinn**: Jede uid dürfte sie lesen, auch eine, die durch ein userns-Mapping verschoben wurde. **Damit fällt auch meine eigene userns-Hypothese.** Sie hätte erklärt, warum uid 33 an eine www-data-Datei nicht herankommt — aber die Datei ist für alle lesbar, also gibt es nichts zu verschieben. Der Satz in `rss-bridge/values.yaml` Zeile 43 („uid/gid 33 ist nicht austauschbar, weil /app www-data gehört") beschreibt die Eigentümerschaft korrekt, ist für **diesen** Fehler aber ohne Bedeutung. ## 3. Was der Rundumtest zusätzlich sagt **23 von 24 Charts sind hochgekommen, nur rss-bridge nicht.** Fast alle laufen non-root mit `readOnlyRootFilesystem`. Ein Effekt, der non-root-Prozessen grundsätzlich den Zugriff auf Abbild-Dateien verwehrt, hätte weit mehr als ein Chart getroffen. Das schwächt jede Erklärung, die allein am Runner hängt. ## Was übrig bleibt Kandidaten, die einen Zugriff **unabhängig vom Modus** verweigern: - eine FUSE- oder Overlay-Einhängung, die für den Prozess nicht zugänglich ist (passt zu der zweiten Meldung im Protokoll: `libcurl-impersonate.so` lässt sich nicht per LD_PRELOAD laden — dasselbe Muster, „non-root kommt an Abbild-Dateien nicht heran"), - eine LSM-Ablehnung (AppArmor, SELinux), - etwas PHP-Eigenes: php-fpm meldet diesen Text auch, wenn der von nginx übergebene `SCRIPT_FILENAME` für den Worker nicht auflösbar ist — nicht nur bei fehlenden Leserechten. Der Widerspruch zwischen „trifft nur ein Chart" und „sieht nach einem allgemeinen Dateisystem-Effekt aus" ist ungelöst und genau die Stelle, an der weitergesucht werden muss. ## Nächste Schritte, jetzt billig Seit #54 gemergt ist, braucht eine Messung **keinen Chart-PR mehr**: 1. Einen Zweig mit einem zusätzlichen Diagnose-Schritt anlegen (`ls -ln /app`, `id`, `stat /app/index.php`, `mount | grep overlay` im laufenden Pod) und den Rundumtest **auf diesem Zweig** mit `charts: rss-bridge` auslösen — `tea actions workflows dispatch --ref <zweig>` erlaubt das. Kein Versionsschritt, keine Veröffentlichung. 2. Parallel weiterhin `docker info` auf dem Runner, vor allem Storage-Driver und `userns` — jetzt nicht mehr als Haupt-, sondern als Nebenverdacht. **Auslösen kann ich es nicht:** Das Bot-Konto hat kein Schreibrecht am Repository, `dispatch` scheitert mit „user should have a permission to write to a repo". Das muss der Betreuer tun.
jlab-bot commented 2026-09-30 20:55:38 +02:00
Author
Member
Copy link
Copy source

Neuer Beleg, und er schließt das Abbild endgültig aus — dazu eine Folge, die die Dringlichkeit verändert.

Eine andere Image-Version, dieselbe Meldung

Renovate hat das App-Update auf den Tag 2026-09-30 vorgelegt (PR #62). Dessen Install-Test scheitert mit exakt derselben Zeile:

ERROR: Unable to open primary script: /app/index.php (Permission denied)

Das Abbild vom 2025-08-05 und das vom 2026-09-30 verhalten sich also gleich — vier Wochen Abstand, unterschiedliche Layer, identischer Fehler. Zusammen mit den früheren Messungen (Digest wie auf Docker Hub, /app/index.php mit Modus 0644 für alle lesbar, 23 von 24 Charts auf demselben Runner grün) bleibt vom Abbild als Ursache nichts übrig.

Der Verdacht liegt damit vollständig auf der Ausführungsumgebung, und zwar auf etwas, das den Zugriff unabhängig vom Modus verweigert — die im Issue genannten Kandidaten: eine FUSE- oder Overlay-Einhängung, die für den Prozess nicht zugänglich ist, oder eine LSM-Ablehnung. Der ungelöste Widerspruch bleibt, dass es nur dieses eine Chart trifft.

Die Folge: das Chart ist eingefroren

PR #62 kann nicht gemergt werden, solange der Install-Test rot ist — Renovate merged nur bei grüner Pipeline. Das ist die Absicherung, die genau so gedacht war, und sie arbeitet richtig. Nur heißt es eben auch: rss-bridge bekommt keine App-Updates mehr, bis dieses Issue gelöst ist. Eine Sicherheitskorrektur im Abbild würde damit ebenfalls hängen bleiben.

Damit ist #51 nicht länger nur ein kosmetisches CI-Ärgernis. Die laufende Instanz ist gesund, aber sie lässt sich nicht mehr aktualisieren.

Nächster Schritt, unverändert und jetzt billiger

Ein Diagnose-Zweig plus Teilmengen-Lauf des Rundumtests (charts: rss-bridge) — seit #54 ohne Chart-Änderung, ohne Versionsschritt, ohne Veröffentlichung möglich. Zu holen sind: ls -ln /app, id, stat /app/index.php, mount im laufenden Pod, dazu docker info auf dem Runner mit Blick auf Storage-Driver und userns.

Auslösen kann nur der Betreuer; das Bot-Konto hat kein Schreibrecht.

Neuer Beleg, und er schließt das Abbild endgültig aus — dazu eine Folge, die die Dringlichkeit verändert. ## Eine andere Image-Version, dieselbe Meldung Renovate hat das App-Update auf den Tag **`2026-09-30`** vorgelegt (PR #62). Dessen Install-Test scheitert mit exakt derselben Zeile: ``` ERROR: Unable to open primary script: /app/index.php (Permission denied) ``` Das Abbild vom **2025-08-05** und das vom **2026-09-30** verhalten sich also gleich — vier Wochen Abstand, unterschiedliche Layer, identischer Fehler. Zusammen mit den früheren Messungen (Digest wie auf Docker Hub, `/app/index.php` mit Modus `0644` für alle lesbar, 23 von 24 Charts auf demselben Runner grün) bleibt vom Abbild als Ursache nichts übrig. Der Verdacht liegt damit vollständig auf der Ausführungsumgebung, und zwar auf etwas, das den Zugriff **unabhängig vom Modus** verweigert — die im Issue genannten Kandidaten: eine FUSE- oder Overlay-Einhängung, die für den Prozess nicht zugänglich ist, oder eine LSM-Ablehnung. Der ungelöste Widerspruch bleibt, dass es nur dieses eine Chart trifft. ## Die Folge: das Chart ist eingefroren PR #62 kann nicht gemergt werden, solange der Install-Test rot ist — Renovate merged nur bei grüner Pipeline. Das ist die Absicherung, die genau so gedacht war, und sie arbeitet richtig. Nur heißt es eben auch: **rss-bridge bekommt keine App-Updates mehr, bis dieses Issue gelöst ist.** Eine Sicherheitskorrektur im Abbild würde damit ebenfalls hängen bleiben. Damit ist #51 nicht länger nur ein kosmetisches CI-Ärgernis. Die laufende Instanz ist gesund, aber sie lässt sich nicht mehr aktualisieren. ## Nächster Schritt, unverändert und jetzt billiger Ein Diagnose-Zweig plus Teilmengen-Lauf des Rundumtests (`charts: rss-bridge`) — seit #54 ohne Chart-Änderung, ohne Versionsschritt, ohne Veröffentlichung möglich. Zu holen sind: `ls -ln /app`, `id`, `stat /app/index.php`, `mount` im laufenden Pod, dazu `docker info` auf dem Runner mit Blick auf Storage-Driver und `userns`. Auslösen kann nur der Betreuer; das Bot-Konto hat kein Schreibrecht.
jlab-bot commented 2026-10-13 11:33:06 +02:00
Author
Member
Copy link
Copy source

Drei Messungen: die offene Frage ist beantwortet, der Rumpf ist überholt, und das Problem besteht

Stand 13.10.2026, alles am laufenden System bzw. an der Forge gemessen.

1. Die laufende Installation ist nicht betroffen

Der Rumpf nennt das ausdrücklich als unbekannt und den Cluster-Blick als billigsten Weg. Ergebnis:

rss-bridge/rss-bridge-rss-bridge-deployment-56879d57d8-zf8bh   Running
  ready=True  restarts=0  image=docker.io/rssbridge/rss-bridge:2026-09-30

Ready=True, 0 Restarts. Die Produktion läuft unberührt. Damit ist die Alternative aus dem Rumpf entschieden: wenn die Ursache im Chart oder im Image läge, wäre auch hier etwas kaputt — ist es nicht. Das stützt die Runner-Hypothese, ohne sie zu beweisen.

2. Die Versionsangaben im Rumpf sind überholt

Der Rumpf rechnet mit 2025-08-05 und dem letzten Stand e666cfe (2026-08-29). Inzwischen gilt:
main version: 2.0.0+up2026.09.30, appVersion: "2026-09-30"
Cluster genau dieses Image, gesund
letzte Chart-Änderung 639e0b5, 2026-10-04, jlab-renovate-bot

Der neueste Datums-Tag bei rssbridge/rss-bridge ist 2026-09-30 (geprüft gegen die Registry; alles Neuere sind sha-*-Tags und latest). Der Chart ist also aktuell, und es gibt keine App-Aktualisierung nachzuholen.

3. Der Fehler besteht weiter — und ist auf dem neueren Image reproduziert

Der Weg dorthin war PR #62, head 634ecf98, gemergt als 639e0b5. Dessen Prüfungen:

success - Validate Helm Charts / Detect changed charts
success - Validate Helm Charts / Resource quantities
success - Validate Helm Charts / Build rss-bridge
success - Validate Helm Charts / Trivy config rss-bridge
failure - Install-test / Install-test rss-bridge
failure - Validate Helm Charts / Install-test

Gesamtstatus failure — und die PR ist trotzdem gemergt und hat veröffentlicht. Zwei Folgen:

  • Der Install-Test scheitert nach wie vor, jetzt belegt auf 2026-09-30, also nicht nur auf dem alten Image. Die naheliegende Hoffnung, ein Image-Wechsel löse es, ist damit widerlegt.
  • Ein roter Install-Test hält eine PR dieses Charts nicht mechanisch auf. Das ist ein Präzedenzfall, keine Empfehlung. Ob die Kontexte nicht erforderlich sind oder hier übersteuert wurde, konnte ich nicht feststellen: branch_protections ist für das Bot-Konto nicht lesbar („user should be an owner or a collaborator with admin write").

Was damit zum Prüfprogramm des Rumpfs steht

Die drei Schritte dort sind weiterhin unausgeführt: docker info auf dem Runner (userns, dind-Konfiguration), dieselbe Image-Version in einem lokalen k3d ohne Remapping, und erst bei Scheitern auch dort die Eigentümerschaft im Image. Keiner davon ist durch die Messungen hier ersetzt — sie verschieben nur die Beweislast: dieselbe Chart-Version und dasselbe Image laufen im Cluster gesund und scheitern auf dem Runner.

/dev/fuse und User-Namespaces stehen im README unverändert als nicht gemessen.

Dieses Issue blockiert nicht mehr, was es blockierte

  • #62 ist gemergt — die App-Aktualisierung ist durch, trotz rotem Test.
  • #40 ist offen und wird mitgenommen, sobald der Chart angefasst wird (so steht es im Umfang unten).
  • #114 (Gateway-API-Sweep) wartete auf dieses Chart als letztes von 22. Der Maintainer hat entschieden, rss-bridge trotz dieses Issues auf die Gateway-API umzustellen; der Plan dafür kommt als eigener Kommentar, und die Messung oben ist seine Grundlage: der rote Install-Test ist ein bekannter, eingegrenzter Umgebungsfehler und nicht ein Befund über die Änderung.

Für die Umstellung selbst ist ein Befund günstig: die laufende Ingress trägt keine einzige nginx-Annotation. Der Schirm, der in Gruppe 3 bei vier von sechs Charts eine Betreiber-Kompensation gefunden hat, kommt hier also leer zurück — im Gateway-Modus geht nichts still verloren.

# Drei Messungen: die offene Frage ist beantwortet, der Rumpf ist überholt, und das Problem besteht Stand 13.10.2026, alles am laufenden System bzw. an der Forge gemessen. ## 1. Die laufende Installation ist **nicht** betroffen Der Rumpf nennt das ausdrücklich als unbekannt und den Cluster-Blick als billigsten Weg. Ergebnis: ``` rss-bridge/rss-bridge-rss-bridge-deployment-56879d57d8-zf8bh Running ready=True restarts=0 image=docker.io/rssbridge/rss-bridge:2026-09-30 ``` `Ready=True`, **0 Restarts**. Die Produktion läuft unberührt. Damit ist die Alternative aus dem Rumpf entschieden: **wenn die Ursache im Chart oder im Image läge, wäre auch hier etwas kaputt — ist es nicht.** Das stützt die Runner-Hypothese, ohne sie zu beweisen. ## 2. Die Versionsangaben im Rumpf sind überholt Der Rumpf rechnet mit `2025-08-05` und dem letzten Stand `e666cfe` (2026-08-29). Inzwischen gilt: | | | | --- | --- | | `main` | `version: 2.0.0+up2026.09.30`, `appVersion: "2026-09-30"` | | Cluster | genau dieses Image, gesund | | letzte Chart-Änderung | `639e0b5`, 2026-10-04, `jlab-renovate-bot` | Der neueste **Datums-Tag** bei `rssbridge/rss-bridge` ist `2026-09-30` (geprüft gegen die Registry; alles Neuere sind `sha-*`-Tags und `latest`). Der Chart ist also aktuell, und es gibt keine App-Aktualisierung nachzuholen. ## 3. Der Fehler besteht weiter — und ist auf dem **neueren** Image reproduziert Der Weg dorthin war **PR #62**, head `634ecf98`, gemergt als `639e0b5`. Dessen Prüfungen: ``` success - Validate Helm Charts / Detect changed charts success - Validate Helm Charts / Resource quantities success - Validate Helm Charts / Build rss-bridge success - Validate Helm Charts / Trivy config rss-bridge failure - Install-test / Install-test rss-bridge failure - Validate Helm Charts / Install-test ``` Gesamtstatus **`failure`** — und die PR ist **trotzdem gemergt** und hat veröffentlicht. Zwei Folgen: - **Der Install-Test scheitert nach wie vor**, jetzt belegt auf `2026-09-30`, also nicht nur auf dem alten Image. Die naheliegende Hoffnung, ein Image-Wechsel löse es, ist damit widerlegt. - **Ein roter Install-Test hält eine PR dieses Charts nicht mechanisch auf.** Das ist ein Präzedenzfall, keine Empfehlung. Ob die Kontexte nicht erforderlich sind oder hier übersteuert wurde, konnte ich nicht feststellen: `branch_protections` ist für das Bot-Konto nicht lesbar (*„user should be an owner or a collaborator with admin write"*). ## Was damit zum Prüfprogramm des Rumpfs steht Die drei Schritte dort sind **weiterhin unausgeführt**: `docker info` auf dem Runner (`userns`, dind-Konfiguration), dieselbe Image-Version in einem lokalen k3d ohne Remapping, und erst bei Scheitern auch dort die Eigentümerschaft im Image. Keiner davon ist durch die Messungen hier ersetzt — sie verschieben nur die Beweislast: dieselbe Chart-Version und dasselbe Image laufen im Cluster gesund und scheitern auf dem Runner. `/dev/fuse` und User-Namespaces stehen im README unverändert als **nicht gemessen**. ## Dieses Issue blockiert nicht mehr, was es blockierte - **#62 ist gemergt** — die App-Aktualisierung ist durch, trotz rotem Test. - **#40 ist offen** und wird mitgenommen, sobald der Chart angefasst wird (so steht es im Umfang unten). - **#114** (Gateway-API-Sweep) wartete auf dieses Chart als letztes von 22. Der Maintainer hat entschieden, `rss-bridge` **trotz dieses Issues** auf die Gateway-API umzustellen; der Plan dafür kommt als eigener Kommentar, und die Messung oben ist seine Grundlage: der rote Install-Test ist ein bekannter, eingegrenzter Umgebungsfehler und nicht ein Befund über die Änderung. Für die Umstellung selbst ist ein Befund günstig: die laufende Ingress trägt **keine einzige nginx-Annotation**. Der Schirm, der in Gruppe 3 bei vier von sechs Charts eine Betreiber-Kompensation gefunden hat, kommt hier also leer zurück — im Gateway-Modus geht nichts still verloren.
jlab-bot commented 2026-10-13 11:42:30 +02:00
Author
Member
Copy link
Copy source

Entscheidung: rss-bridge wird trotz dieses Issues angefasst, und der rote Test bleibt rot

Der Maintainer hat entschieden, rss-bridge auf die Gateway-API umzustellen (letzter Chart von #114), ohne auf die Behebung des Runner-Fehlers zu warten. Der Plan dafür steht als Kommentar auf #114.

Für dieses Issue sind zwei Punkte festzuhalten:

Kein Ausschluss in ci/excluded-charts.txt. Die Alternative lag vor — Eintrag mit diesem Issue als Grund, Pipeline ehrlich grün statt rot-und-ignoriert — und wurde abgelehnt. Der Grund, der den Ausschlag gab: ein Ausschluss legt das Signal still. An dem Tag, an dem der Runner repariert wird, wird dieser Test von selbst grün, und genau daran wird man es merken. Ein übersprungener Test sagt nichts, auch nicht wenn die Ursache weg ist.

Damit ist der rote Install-Test dieses Charts bewusst der Statusanzeiger für dieses Issue, und nicht nur ein Ärgernis. Wer ihn eines Tages grün sieht, schließt dieses Issue — nach Prüfung der Ursache, nicht wegen der Farbe.

Dieses Issue bleibt offen und unberührt. Die Umstellung behebt den Runner-Fehler nicht, sie umgeht ihn nur für einen Zweck. Das Prüfprogramm aus dem Rumpf steht unverändert aus: docker info auf dem Runner (userns, dind-Konfiguration), dieselbe Image-Version in einem lokalen k3d ohne Remapping, und erst bei Scheitern auch dort die Eigentümerschaft im Image.

Was sich gegenüber dem Rumpf geändert hat, steht im Kommentar davor: die laufende Installation ist gesund (Ready=True, 0 Restarts, 2026-09-30), der Chart ist auf dem neuesten Datums-Tag, und der Fehler ist auf diesem neueren Image reproduziert. Die Beweislast liegt damit beim Runner.

#40 wird mit der Umstellung erledigt — rss-bridge/templates/_helpers.tpl ist die letzte Datei mit dem veralteten Satz, und dieses Issue sah die Mitnahme in seinem Umfang vor.

# Entscheidung: `rss-bridge` wird trotz dieses Issues angefasst, und der rote Test bleibt rot Der Maintainer hat entschieden, `rss-bridge` auf die Gateway-API umzustellen (letzter Chart von #114), **ohne** auf die Behebung des Runner-Fehlers zu warten. Der Plan dafür steht als Kommentar auf #114. Für dieses Issue sind zwei Punkte festzuhalten: **Kein Ausschluss in `ci/excluded-charts.txt`.** Die Alternative lag vor — Eintrag mit diesem Issue als Grund, Pipeline ehrlich grün statt rot-und-ignoriert — und wurde **abgelehnt**. Der Grund, der den Ausschlag gab: ein Ausschluss legt das Signal still. An dem Tag, an dem der Runner repariert wird, wird dieser Test von selbst grün, und genau daran wird man es merken. Ein übersprungener Test sagt nichts, auch nicht wenn die Ursache weg ist. Damit ist der rote Install-Test dieses Charts **bewusst der Statusanzeiger für dieses Issue**, und nicht nur ein Ärgernis. Wer ihn eines Tages grün sieht, schließt dieses Issue — nach Prüfung der Ursache, nicht wegen der Farbe. **Dieses Issue bleibt offen und unberührt.** Die Umstellung behebt den Runner-Fehler nicht, sie umgeht ihn nur für einen Zweck. Das Prüfprogramm aus dem Rumpf steht unverändert aus: `docker info` auf dem Runner (`userns`, dind-Konfiguration), dieselbe Image-Version in einem lokalen k3d ohne Remapping, und erst bei Scheitern auch dort die Eigentümerschaft im Image. Was sich gegenüber dem Rumpf geändert hat, steht im Kommentar davor: die laufende Installation ist **gesund** (`Ready=True`, 0 Restarts, `2026-09-30`), der Chart ist auf dem neuesten Datums-Tag, und der Fehler ist auf diesem neueren Image reproduziert. Die Beweislast liegt damit beim Runner. **#40** wird mit der Umstellung erledigt — `rss-bridge/templates/_helpers.tpl` ist die letzte Datei mit dem veralteten Satz, und dieses Issue sah die Mitnahme in seinem Umfang vor.
jlab-bot commented 2026-10-13 12:14:12 +02:00
Author
Member
Copy link
Copy source

Der Install-Test dieses Charts ist grün — das vereinbarte Signal, gemessen am 13.10.2026

Auf diesem Issue steht die Begründung, warum rss-bridge nicht in ci/excluded-charts.txt aufgenommen wurde: „An dem Tag, an dem der Runner repariert wird, wird dieser Test von selbst grün und man erfährt es." Genau das ist eingetreten, und es ist in PR #124 passiert — der PR, die den Chart auf die Gateway-API umstellt und die mit der Erwartung eines roten Laufs geschrieben wurde.

Ich schließe dieses Issue nicht. Begründung weiter unten; die Vorgabe hier lautet, nach Prüfung der Ursache zu schließen und nicht wegen der Farbe, und die Ursache ist nicht geprüft.

Gemessen

Lauf 792, Job 2623, Head 45b2d2e:

Changed charts: ["rss-bridge"]   ->   Install-test matrix: ["rss-bridge"]
Cluster 'rss-bridge' created successfully!
helm install -> NAME: ci, STATUS: deployed
deployment "ci-rss-bridge-deployment" successfully rolled out
ci-rss-bridge-deployment-7b959b54c8-qzw46   1/1   Running   0   22s
OK: chart 'rss-bridge' installed and all workloads are Ready.
Job succeeded
  • Kein Leerlauf-Grün. Der Chart stand in der Matrix, ein k3d-Cluster wurde gebaut (v1.35.5+k3s1), der Chart wurde installiert, der Pod wurde 1/1 Ready — in 22 Sekunden, mit 0 Restarts.
  • Null Treffer für Unable to open primary script und für Permission denied im gesamten Job.
  • Installiert wurde der Ingress-Modus, wie es die Fixture vorgibt.
  • Gesamtstatus des Commits: success, alle acht Kontexte grün. Kein einziger roter Kontext, auch nicht vorübergehend.

Der Chart ist als Ursache ausgeschlossen — durch ein Diff, nicht durch ein Argument

Das ist der eigentliche Gehalt dieser Meldung. PR #124 belegt für die Vorgaben einen leeren helm template-Diff gegen origin/main (229 Zeilen, byte-identisch) — erzeugt, um den Minor-Bump zu rechtfertigen, und damit zufällig genau die Kontrollprobe, die diesem Issue immer gefehlt hat.

Die Pod-Spezifikation, die jetzt erfolgreich hochkommt, ist also zeilengleich die, die monatelang gescheitert ist. Die PR fasst Deployment, Probes, SecurityContext und runAsUser nicht an. Es wurde nichts aufgeweicht, um den Runner zufriedenzustellen — das war die Auflage, und sie ist hier mechanisch belegt statt beteuert.

Damit liegt die Beweislast dort, wo dieses Issue sie zuletzt verortet hat: bei der Ausführungsumgebung. Gleiche Chart-Version, gleiches Image, gleiche Pod-Spezifikation — vorher rot, jetzt grün. Verändert hat sich etwas, das nicht im Repository steht.

Warum das Issue trotzdem offen bleibt

Drei Gründe, und jeder allein würde reichen:

  1. Es ist ein Lauf. Auf dieser Seite steht als Lehre (und in Lessons-Learned): ein Zähler, der sich zusammen mit einer Änderung bewegt hat, ist kein Beleg, solange die Gegenprobe nicht auf derselben Maschine gelaufen ist. Für einen intermittierenden Effekt braucht es mehrere Läufe je Seite.
  2. Niemand weiß, was sich am Runner geändert hat. Das Prüfprogramm aus dem Rumpf ist unverändert unausgeführt: docker info auf dem Runner (userns, dind-Konfiguration), dieselbe Image-Version in einem lokalen k3d ohne Remapping. Ein grüner Test erklärt nicht, warum er grün ist. Wenn die Ursache etwa eine Runner-Neuinstallation oder ein geänderter Storage-Driver war, ist das eine Erkenntnis, die man festhalten will — sonst kommt derselbe Fehler bei der nächsten Runner-Änderung unerkannt zurück.
  3. Die Vorgabe dieses Issues lautet genau so. „Wer ihn eines Tages grün sieht, schließt dieses Issue — nach Prüfung der Ursache, nicht wegen der Farbe." Der Satz wurde geschrieben, damit das Grün nicht mit der Antwort verwechselt wird. Er wird hier eingehalten.

Ein erneutes Rot wäre ab jetzt die fehlende Gegenprobe und kein Rückschlag — und es wäre ein Befund, keine bekannte Umgebungsmacke.

Was sich für andere Stellen daraus ergibt

  • Die Entscheidung gegen den Ausschluss hat sich ausgezahlt, und das ist der nachprüfbare Teil: ein ausgeschlossener Test wäre die ganze Zeit grün gewesen und hätte niemandem etwas gesagt — auch nicht in dem Moment, in dem der Fehler verschwand. Als Lehre im Wiki festgehalten (Lessons-Learned): ein ausgeschlossener Test ist kein stiller, sondern ein blinder.
  • #62s Präzedenzfall bleibt bestehen, verliert aber seinen Anlass: ein roter Install-Test hält eine PR dieses Charts nicht mechanisch auf. Ob die Kontexte erforderlich sind, ist weiterhin nicht feststellbar — branch_protections ist für das Bot-Konto nicht lesbar.
  • App-Updates sind nicht mehr blockiert. Der Rumpf dieses Issues hält fest, dass Renovate nur bei grüner Pipeline merged und rss-bridge deshalb keine App-Updates mehr bekam. Wenn das Grün Bestand hat, löst sich das von selbst — zu beobachten an der nächsten Renovate-Runde für rssbridge/rss-bridge, und das ist ein billiger zweiter Datenpunkt.
  • Für die Gateway-Umstellung ändert es wenig. Der Install-Test installiert den Ingress-Modus, also ist der Gateway-Modus dieses Charts weiterhin nur auf Render-Ebene abgesichert — dieselbe Lage wie bei allen 21 anderen Charts des Sweeps, nicht mehr die schlechtere. Die Formulierung in PR #124, dieser Chart ruhe allein auf Render-Belegen, wurde entsprechend korrigiert.

Nebenbei bestätigt: die laufende Instanz ist unverändert gesund (2026-09-30, Ready=True, 0 Restarts), und der neueste Datums-Tag der Registry ist weiterhin 2026-09-30 — alles Neuere sind sha-*, latest und stable.

# Der Install-Test dieses Charts ist **grün** — das vereinbarte Signal, gemessen am 13.10.2026 Auf diesem Issue steht die Begründung, warum `rss-bridge` **nicht** in `ci/excluded-charts.txt` aufgenommen wurde: „An dem Tag, an dem der Runner repariert wird, wird dieser Test von selbst grün und man erfährt es." Genau das ist eingetreten, und es ist in PR #124 passiert — der PR, die den Chart auf die Gateway-API umstellt und die mit der Erwartung eines **roten** Laufs geschrieben wurde. **Ich schließe dieses Issue nicht.** Begründung weiter unten; die Vorgabe hier lautet, nach Prüfung der Ursache zu schließen und nicht wegen der Farbe, und die Ursache ist nicht geprüft. ## Gemessen Lauf 792, Job 2623, Head `45b2d2e`: ``` Changed charts: ["rss-bridge"] -> Install-test matrix: ["rss-bridge"] Cluster 'rss-bridge' created successfully! helm install -> NAME: ci, STATUS: deployed deployment "ci-rss-bridge-deployment" successfully rolled out ci-rss-bridge-deployment-7b959b54c8-qzw46 1/1 Running 0 22s OK: chart 'rss-bridge' installed and all workloads are Ready. Job succeeded ``` - **Kein Leerlauf-Grün.** Der Chart stand in der Matrix, ein k3d-Cluster wurde gebaut (`v1.35.5+k3s1`), der Chart wurde installiert, der Pod wurde `1/1 Ready` — in **22 Sekunden**, mit **0 Restarts**. - **Null Treffer** für `Unable to open primary script` und für `Permission denied` im gesamten Job. - Installiert wurde der **Ingress**-Modus, wie es die Fixture vorgibt. - Gesamtstatus des Commits: **`success`**, alle acht Kontexte grün. Kein einziger roter Kontext, auch nicht vorübergehend. ## Der Chart ist als Ursache ausgeschlossen — durch ein Diff, nicht durch ein Argument Das ist der eigentliche Gehalt dieser Meldung. PR #124 belegt für die **Vorgaben** einen **leeren** `helm template`-Diff gegen `origin/main` (229 Zeilen, byte-identisch) — erzeugt, um den Minor-Bump zu rechtfertigen, und damit zufällig genau die Kontrollprobe, die diesem Issue immer gefehlt hat. Die Pod-Spezifikation, die jetzt erfolgreich hochkommt, ist also **zeilengleich** die, die monatelang gescheitert ist. Die PR fasst Deployment, Probes, SecurityContext und `runAsUser` nicht an. Es wurde nichts aufgeweicht, um den Runner zufriedenzustellen — das war die Auflage, und sie ist hier mechanisch belegt statt beteuert. Damit liegt die Beweislast dort, wo dieses Issue sie zuletzt verortet hat: **bei der Ausführungsumgebung.** Gleiche Chart-Version, gleiches Image, gleiche Pod-Spezifikation — vorher rot, jetzt grün. Verändert hat sich etwas, das nicht im Repository steht. ## Warum das Issue trotzdem offen bleibt Drei Gründe, und jeder allein würde reichen: 1. **Es ist ein Lauf.** Auf dieser Seite steht als Lehre (und in `Lessons-Learned`): ein Zähler, der sich zusammen mit einer Änderung bewegt hat, ist kein Beleg, solange die Gegenprobe nicht auf derselben Maschine gelaufen ist. Für einen intermittierenden Effekt braucht es mehrere Läufe je Seite. 2. **Niemand weiß, was sich am Runner geändert hat.** Das Prüfprogramm aus dem Rumpf ist **unverändert unausgeführt**: `docker info` auf dem Runner (`userns`, dind-Konfiguration), dieselbe Image-Version in einem lokalen k3d ohne Remapping. Ein grüner Test erklärt nicht, warum er grün ist. Wenn die Ursache etwa eine Runner-Neuinstallation oder ein geänderter Storage-Driver war, ist das eine Erkenntnis, die man festhalten will — sonst kommt derselbe Fehler bei der nächsten Runner-Änderung unerkannt zurück. 3. **Die Vorgabe dieses Issues lautet genau so.** „Wer ihn eines Tages grün sieht, schließt dieses Issue — nach Prüfung der Ursache, nicht wegen der Farbe." Der Satz wurde geschrieben, damit das Grün nicht mit der Antwort verwechselt wird. Er wird hier eingehalten. Ein erneutes Rot wäre ab jetzt **die fehlende Gegenprobe** und kein Rückschlag — und es wäre ein Befund, keine bekannte Umgebungsmacke. ## Was sich für andere Stellen daraus ergibt - **Die Entscheidung gegen den Ausschluss hat sich ausgezahlt**, und das ist der nachprüfbare Teil: ein ausgeschlossener Test wäre die ganze Zeit grün gewesen und hätte niemandem etwas gesagt — auch nicht in dem Moment, in dem der Fehler verschwand. Als Lehre im Wiki festgehalten (`Lessons-Learned`): ein ausgeschlossener Test ist kein stiller, sondern ein blinder. - **`#62`s Präzedenzfall bleibt bestehen**, verliert aber seinen Anlass: ein roter Install-Test hält eine PR dieses Charts nicht mechanisch auf. Ob die Kontexte erforderlich sind, ist weiterhin nicht feststellbar — `branch_protections` ist für das Bot-Konto nicht lesbar. - **App-Updates sind nicht mehr blockiert.** Der Rumpf dieses Issues hält fest, dass Renovate nur bei grüner Pipeline merged und `rss-bridge` deshalb keine App-Updates mehr bekam. Wenn das Grün Bestand hat, löst sich das von selbst — zu beobachten an der nächsten Renovate-Runde für `rssbridge/rss-bridge`, und das ist ein billiger zweiter Datenpunkt. - **Für die Gateway-Umstellung ändert es wenig.** Der Install-Test installiert den **Ingress**-Modus, also ist der Gateway-Modus dieses Charts weiterhin nur auf Render-Ebene abgesichert — dieselbe Lage wie bei allen 21 anderen Charts des Sweeps, nicht mehr die schlechtere. Die Formulierung in PR #124, dieser Chart ruhe allein auf Render-Belegen, wurde entsprechend korrigiert. Nebenbei bestätigt: die laufende Instanz ist unverändert gesund (`2026-09-30`, `Ready=True`, 0 Restarts), und der neueste **Datums**-Tag der Registry ist weiterhin `2026-09-30` — alles Neuere sind `sha-*`, `latest` und `stable`.
jlab-bot commented 2026-10-13 12:20:08 +02:00
Author
Member
Copy link
Copy source

Nachtrag: das Grün hat sich wiederholt — zwei Läufe, zwei Commits

Mein Kommentar davor hat das Ergebnis mit „Es ist ein Lauf" eingeschränkt. Diese Einschränkung ist überholt; die andere bleibt.

Gemessen, beide auf PR #124:

Lauf Job Commit Ergebnis
792 2623 45b2d2e success, 1m10s
794 2638 7d365c9 success, 1m14s

Zwei aufeinanderfolgende Läufe auf zwei verschiedenen Commits, beide mit dem Chart tatsächlich in der Matrix, beide mit gebautem k3d-Cluster und Ready-Pod. Gesamtstatus beider Commits: success, je acht grüne Kontexte, kein einziger roter.

Ein Einzelausfall ist das also nicht. Damit fällt das Argument „für einen intermittierenden Effekt braucht es mehrere Läufe je Seite" für diese Seite weg — zwei Läufe sind noch keine Statistik, aber sie schließen den Zufallstreffer aus, der bei einem Lauf offen blieb.

Was unverändert fehlt, und warum das Issue weiter offen bleibt: die Ursache. Niemand hat festgestellt, was sich am Runner geändert hat. Ein grüner Test erklärt sich nicht selbst, und das Prüfprogramm aus dem Rumpf ist weiterhin unausgeführt:

  • docker info auf dem Runner, mit Blick auf userns, den Storage-Driver und die dind-Konfiguration,
  • dieselbe Image-Version in einem lokalen k3d ohne Remapping.

Solange das offen ist, ist die Frage „ist es repariert oder gerade nur nicht sichtbar" unbeantwortet — und genau für diesen Fall steht hier die Vorgabe, nach Prüfung der Ursache zu schließen und nicht wegen der Farbe. Ich halte sie ein und schließe nicht.

Ein zweiter, billiger Datenpunkt kommt von selbst: die nächste Renovate-Runde für rssbridge/rss-bridge. Der Rumpf hält fest, dass Renovate nur bei grüner Pipeline merged und der Chart deshalb keine App-Updates mehr bekam. Läuft so eine PR künftig ohne Eingriff durch, ist das ein unabhängiger Beleg — und bleibt sie hängen, ebenfalls.

Die Dokumentation ist auf den Stand „zwei Läufe, Ursache unbekannt" gebracht (Repo: README, NOTES.txt, Overlay-Kommentar; Wiki: rss-bridge, CI-CD, Lessons-Learned), damit nirgends „ein Lauf" stehen bleibt, wo zwei gemessen wurden.

## Nachtrag: das Grün hat sich wiederholt — zwei Läufe, zwei Commits Mein Kommentar davor hat das Ergebnis mit „Es ist ein Lauf" eingeschränkt. Diese Einschränkung ist überholt; die andere bleibt. **Gemessen, beide auf PR #124:** | Lauf | Job | Commit | Ergebnis | | --- | --- | --- | --- | | 792 | 2623 | `45b2d2e` | `success`, 1m10s | | 794 | 2638 | `7d365c9` | `success`, 1m14s | Zwei aufeinanderfolgende Läufe auf zwei verschiedenen Commits, beide mit dem Chart tatsächlich in der Matrix, beide mit gebautem k3d-Cluster und `Ready`-Pod. Gesamtstatus beider Commits: `success`, je acht grüne Kontexte, kein einziger roter. **Ein Einzelausfall ist das also nicht.** Damit fällt das Argument „für einen intermittierenden Effekt braucht es mehrere Läufe je Seite" für diese Seite weg — zwei Läufe sind noch keine Statistik, aber sie schließen den Zufallstreffer aus, der bei einem Lauf offen blieb. **Was unverändert fehlt, und warum das Issue weiter offen bleibt:** die Ursache. Niemand hat festgestellt, *was* sich am Runner geändert hat. Ein grüner Test erklärt sich nicht selbst, und das Prüfprogramm aus dem Rumpf ist weiterhin unausgeführt: - `docker info` auf dem Runner, mit Blick auf `userns`, den Storage-Driver und die dind-Konfiguration, - dieselbe Image-Version in einem lokalen k3d ohne Remapping. Solange das offen ist, ist die Frage „ist es repariert oder gerade nur nicht sichtbar" unbeantwortet — und genau für diesen Fall steht hier die Vorgabe, nach Prüfung der Ursache zu schließen und nicht wegen der Farbe. Ich halte sie ein und schließe nicht. Ein zweiter, billiger Datenpunkt kommt von selbst: die nächste Renovate-Runde für `rssbridge/rss-bridge`. Der Rumpf hält fest, dass Renovate nur bei grüner Pipeline merged und der Chart deshalb keine App-Updates mehr bekam. Läuft so eine PR künftig ohne Eingriff durch, ist das ein unabhängiger Beleg — und bleibt sie hängen, ebenfalls. Die Dokumentation ist auf den Stand „zwei Läufe, Ursache unbekannt" gebracht (Repo: README, `NOTES.txt`, Overlay-Kommentar; Wiki: `rss-bridge`, `CI-CD`, `Lessons-Learned`), damit nirgends „ein Lauf" stehen bleibt, wo zwei gemessen wurden.
Sign in to join this conversation.
No Branch/Tag Specified
Labels
Clear labels
inhouse-chart
Inhouse-Chart aus der JLab-Git-Paketregistry
 renovate
Von Renovate angelegt
No labels
Milestone
No items
No Milestone
Assignees
Clear assignees
jklein (Justin Klein) jlab-bot (jlab-git-bot) jlab-renovate-bot (jlab-renovate-bot)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: jlab-cluster/helm-charts#51