ci/<chart>/fixtures.yaml: Images werden von Renovate nicht verfolgt und altern still #24

Open
opened 2026-09-17 10:39:43 +02:00 by jlab-bot · 1 comment
Member

Migriert aus jk-cluster/helm-charts#257 — urspruenglich angelegt von jk-cluster-bot am 2026-09-16.

Verweise der Form #123 im folgenden Text beziehen sich auf die GitHub-Nummerierung. Die Zuordnungstabelle steht als Kommentar an #14.


Die Images in ci/<chart>/fixtures*.yaml werden von Renovate nicht verfolgt. Sie altern still, und die Infrastruktur, gegen die unsere Charts geprüft werden, driftet dabei von dem weg, was im Cluster steht.

Befund

Aus renovate.json5 gelesen: Sämtliche managerFilePatterns zeigen auf <chart>/Chart.yaml oder auf .github/workflows/*.yml. Kein einziges Muster deckt ci/ ab. Der einzige Treffer für ci/ in der Datei ist der Post-Upgrade-Befehl, der die Chart-Version anhebt — der liest keine Manifeste.

Der eingebaute kubernetes-Manager würde diese Dateien verstehen, ist aber ohne ausdrückliche Konfiguration abgeschaltet (Kubernetes-Manifeste haben keinen festen Dateinamen, deshalb liefert Renovate für diesen Manager kein Vorgabemuster mit). Konfiguriert ist er hier nicht.

Betroffen sind nach heutigem Stand:

Image Bemerkung
ghcr.io/element-hq/synapse:v1.159.0 der unangenehme Fall, siehe unten
ghcr.io/dexidp/dex:v2.41.1 OIDC-Attrappe
public.ecr.aws/docker/library/postgres:16-alpine wandert innerhalb von 16
public.ecr.aws/docker/library/redis:7-alpine wandert innerhalb von 7
public.ecr.aws/docker/library/busybox:1.36 wandert innerhalb von 1.36

Warum der Synapse-Eintrag der schlimmste ist

matrix-synapse/Chart.yaml wird verfolgt — dort hebt Renovate die appVersion. Die Fixture pinnt Synapse ein zweites Mal, und diese Stelle wird nicht gehoben.

Die beiden laufen also auseinander, und zwar in genau der Richtung, die niemandem auffällt: Der Chart zieht auf eine neue Synapse-Version, der Install-Test prüft ihn weiterhin gegen v1.159.0, und der Lauf ist grün. Ein grüner Install-Test behauptet „diese Chart-Version läuft" und meint in Wahrheit „sie lief gegen eine Version, die wir nicht mehr ausliefern".

Das ist dieselbe Klasse wie #184 bis #186: nicht ein Fehler, der etwas kaputt macht, sondern einer, der eine Zusicherung aushöhlt, während alles grün bleibt.

Die drei Bibliotheks-Images sind harmloser, weil ihre Tags innerhalb einer Linie wandern — aber sie wandern eben unbeobachtet, und ein Sicherheits-Fix erreicht die CI dann irgendwann oder auch nicht.

Woher der Hinweis kommt

Aus dem Austausch mit der cluster-config-Sitzung: Dort ist dieselbe Lücke aufgefallen, weil der helm-values-Manager auf *.values.yaml begrenzt ist und Roh-Manifeste unbeobachtet bleiben. Sie haben ausdrücklich darauf hingewiesen, dass für dieses Repo dasselbe gilt. Der Befund hier ist eigenständig geprüft.

Zu belegen — und das ist der Kern

Erst im Trockenlauf zeigen, dass heute nichts vorgeschlagen wird, dann die Regel bauen, dann im Trockenlauf zeigen, dass sie greift. In dieser Reihenfolge.

Dieses Repo ist an genau dieser Stelle schon zweimal aufgelaufen (#158, searxng-Runde): eine gültige Regel ist keine treffende Regel, und ein Fehlschlag ist hier still. Der Befund oben stammt aus dem Lesen der Konfiguration, nicht aus einem Lauf — er ist begründet, aber nicht gemessen.

Zu entscheiden ist dabei auch, ob alle fünf verfolgt werden sollen. Für Synapse ist die Antwort offensichtlich ja. Bei den Bibliotheks-Images ist ein wöchentlicher PR für eine Postgres-Patch-Version in einer Wegwerf-Fixture womöglich mehr Lärm als Gewinn — dann gehört das als Entscheidung dokumentiert, nicht als Lücke belassen.

Hinweis zur Ablage

Angelegt auf GitHub, weil dort bis zum Abschluss von #225 der Arbeitsablauf läuft. Bei der nächsten Runde der Issue-Migration nach JLab-Git mitnehmen — die 17 zuvor migrierten sind bereits drüben.

> Migriert aus [`jk-cluster/helm-charts#257`](https://github.com/jk-cluster/helm-charts/issues/257) — urspruenglich angelegt von **jk-cluster-bot** am 2026-09-16. > > Verweise der Form `#123` im folgenden Text beziehen sich auf die **GitHub-Nummerierung**. Die Zuordnungstabelle steht als Kommentar an #14. --- Die Images in `ci/<chart>/fixtures*.yaml` werden von Renovate **nicht verfolgt**. Sie altern still, und die Infrastruktur, gegen die unsere Charts geprüft werden, driftet dabei von dem weg, was im Cluster steht. ## Befund Aus `renovate.json5` gelesen: Sämtliche `managerFilePatterns` zeigen auf `<chart>/Chart.yaml` oder auf `.github/workflows/*.yml`. **Kein einziges Muster deckt `ci/` ab.** Der einzige Treffer für `ci/` in der Datei ist der Post-Upgrade-Befehl, der die Chart-Version anhebt — der liest keine Manifeste. Der eingebaute `kubernetes`-Manager würde diese Dateien verstehen, ist aber ohne ausdrückliche Konfiguration **abgeschaltet** (Kubernetes-Manifeste haben keinen festen Dateinamen, deshalb liefert Renovate für diesen Manager kein Vorgabemuster mit). Konfiguriert ist er hier nicht. Betroffen sind nach heutigem Stand: | Image | Bemerkung | |---|---| | `ghcr.io/element-hq/synapse:v1.159.0` | **der unangenehme Fall, siehe unten** | | `ghcr.io/dexidp/dex:v2.41.1` | OIDC-Attrappe | | `public.ecr.aws/docker/library/postgres:16-alpine` | wandert innerhalb von 16 | | `public.ecr.aws/docker/library/redis:7-alpine` | wandert innerhalb von 7 | | `public.ecr.aws/docker/library/busybox:1.36` | wandert innerhalb von 1.36 | ## Warum der Synapse-Eintrag der schlimmste ist `matrix-synapse/Chart.yaml` **wird** verfolgt — dort hebt Renovate die appVersion. Die Fixture pinnt Synapse ein zweites Mal, und diese Stelle wird nicht gehoben. Die beiden laufen also auseinander, und zwar in genau der Richtung, die niemandem auffällt: Der Chart zieht auf eine neue Synapse-Version, der Install-Test prüft ihn weiterhin gegen `v1.159.0`, und der Lauf ist **grün**. Ein grüner Install-Test behauptet „diese Chart-Version läuft" und meint in Wahrheit „sie lief gegen eine Version, die wir nicht mehr ausliefern". Das ist dieselbe Klasse wie #184 bis #186: nicht ein Fehler, der etwas kaputt macht, sondern einer, der eine **Zusicherung aushöhlt**, während alles grün bleibt. Die drei Bibliotheks-Images sind harmloser, weil ihre Tags innerhalb einer Linie wandern — aber sie wandern eben **unbeobachtet**, und ein Sicherheits-Fix erreicht die CI dann irgendwann oder auch nicht. ## Woher der Hinweis kommt Aus dem Austausch mit der `cluster-config`-Sitzung: Dort ist dieselbe Lücke aufgefallen, weil der `helm-values`-Manager auf `*.values.yaml` begrenzt ist und Roh-Manifeste unbeobachtet bleiben. Sie haben ausdrücklich darauf hingewiesen, dass für dieses Repo dasselbe gilt. Der Befund hier ist eigenständig geprüft. ## Zu belegen — und das ist der Kern **Erst im Trockenlauf zeigen, dass heute nichts vorgeschlagen wird**, dann die Regel bauen, dann im Trockenlauf zeigen, dass sie greift. In dieser Reihenfolge. Dieses Repo ist an genau dieser Stelle schon zweimal aufgelaufen (#158, searxng-Runde): **eine gültige Regel ist keine treffende Regel**, und ein Fehlschlag ist hier still. Der Befund oben stammt aus dem Lesen der Konfiguration, nicht aus einem Lauf — er ist begründet, aber nicht gemessen. Zu entscheiden ist dabei auch, **ob** alle fünf verfolgt werden sollen. Für Synapse ist die Antwort offensichtlich ja. Bei den Bibliotheks-Images ist ein wöchentlicher PR für eine Postgres-Patch-Version in einer Wegwerf-Fixture womöglich mehr Lärm als Gewinn — dann gehört das als Entscheidung dokumentiert, nicht als Lücke belassen. ## Hinweis zur Ablage Angelegt auf GitHub, weil dort bis zum Abschluss von #225 der Arbeitsablauf läuft. Bei der nächsten Runde der Issue-Migration nach JLab-Git **mitnehmen** — die 17 zuvor migrierten sind bereits drüben.
Author
Member

Nachgeprüft am 2026-10-04: die Hälfte ist inzwischen eine Entscheidung, der Rest steht

Was sich geändert hat. renovate.json5:103-108 trägt jetzt eine ausdrückliche Regel:

matchFileNames: ["ci/**"],
enabled: false,

mit der Begründung, Install-Test-Fixtures pinnten Wegwerf-Infrastruktur bewusst auf Major-Linien (postgres:16-alpine, redis:7-alpine, busybox:1.36), seien Testgerüst und kein ausgeliefertes Artefakt, und ein Nachziehen gefährde nur den Install-Test.

Für diese drei ist das eine gute Antwort: sie wandern innerhalb ihrer Major-Linie, der Pin ist also kein Stillstand. Das „altern still" aus dem Titel trifft sie nicht mehr — es ist dokumentiert statt versehentlich.

Was offen bleibt, und worauf dieses Issue eingegrenzt werden sollte: die zwei harten Pins, die nicht wandern.

Datei Image
ci/matrix-synapse/fixtures.yaml:43 ghcr.io/element-hq/synapse:v1.159.0
ci/patchmon/fixtures.yaml:173 ghcr.io/dexidp/dex:v2.41.1

Diese beiden altern genau so, wie das Issue es beschreibt, und die ci/**-Regel schaltet sie mit ab. Der unangenehme Fall aus dem Issue-Body ist damit unverändert vorhanden — nur ist er jetzt der einzige.

## Nachgeprüft am 2026-10-04: die Hälfte ist inzwischen eine Entscheidung, der Rest steht **Was sich geändert hat.** `renovate.json5:103-108` trägt jetzt eine ausdrückliche Regel: ```json5 matchFileNames: ["ci/**"], enabled: false, ``` mit der Begründung, Install-Test-Fixtures pinnten Wegwerf-Infrastruktur bewusst auf Major-Linien (`postgres:16-alpine`, `redis:7-alpine`, `busybox:1.36`), seien Testgerüst und kein ausgeliefertes Artefakt, und ein Nachziehen gefährde nur den Install-Test. Für diese drei ist das eine gute Antwort: sie wandern innerhalb ihrer Major-Linie, der Pin ist also kein Stillstand. Das „altern still" aus dem Titel trifft sie nicht mehr — es ist dokumentiert statt versehentlich. **Was offen bleibt, und worauf dieses Issue eingegrenzt werden sollte:** die zwei **harten** Pins, die nicht wandern. | Datei | Image | | --- | --- | | `ci/matrix-synapse/fixtures.yaml:43` | `ghcr.io/element-hq/synapse:v1.159.0` | | `ci/patchmon/fixtures.yaml:173` | `ghcr.io/dexidp/dex:v2.41.1` | Diese beiden altern genau so, wie das Issue es beschreibt, und die `ci/**`-Regel schaltet sie mit ab. Der unangenehme Fall aus dem Issue-Body ist damit unverändert vorhanden — nur ist er jetzt der einzige.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: jlab-cluster/helm-charts#24