Install-Test: kein Rundumtest ueber alle Charts - Umgebungsdrift bleibt unentdeckt #52
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: jlab-cluster/helm-charts#52
Reference in new issue
Block a user
Der Install-Test läuft nur für die Charts, die ein PR ändert. Damit gibt es keinen Zeitpunkt, an dem die Charts als Gesamtheit gegen die aktuelle Umgebung geprüft werden — und nach dem Umzug auf Gitea hat sich die Umgebung geändert.
Wie sichtbar wurde, dass das zählt
PR #48 (Issue #40) korrigiert einen Kommentar in 21 Charts. Weil damit alle diese Charts als geändert gelten, ist daraus versehentlich der erste Rundumtest nach dem Umzug geworden:
kubectl, im Auftragscontainer, also unter den Bedingungen, die seit dem Umzug gelten.rss-bridge, siehe #51. Dessen letzter grüner Lauf stammte vom 2026-08-29 und damit von einem GitHub-Runner.Das ist ein wertvolles Ergebnis — und es ist durch Zufall entstanden. Ohne den Kommentar-Durchgang hätte niemand erfahren, dass 19 Charts auf dem neuen Runner starten und eines nicht.
Das Problem
Der Umzug hat die Ausführungsumgebung an mehreren Stellen verändert, von denen die README einige ausdrücklich als unvermessen führt (
/dev/fuse, User-Namespaces). Ein Chart, das seit dem Umzug nicht angefasst wurde, trägt eine grüne Historie aus einer anderen Umgebung. Diese Grünfärbung sagt über heute nichts aus — genau die Sorte Signal, gegen die dieses Repo seine Regeln geschrieben hat („Green does not mean checked").Dasselbe gilt für jede künftige Änderung am Runner, am
K3S_IMAGE, am gepinntenkubectloder an den Fixtures: Sie wird erst dann für ein Chart wirksam geprüft, wenn dieses Chart aus unabhängigem Grund geändert wird. Bei manchen Charts kann das Monate dauern.Vorschlag
Ein manuell auslösbarer Rundumtest: derselbe Install-Test, aber mit einer Matrix über alle nicht ausgeschlossenen Charts statt über die geänderten.
workflow_dispatch, kein Zeitplan, damit er nichts kostet, solange ihn niemand braucht.Zu klären bei der Umsetzung:
K3S_IMAGE, am gepinntenkubectlund nach einem Umzug. Ein Zeitplan wäre die Alternative, kostet aber täglich Rechenzeit für eine Frage, die sich selten ändert.Was dieses Issue nicht ist
Kein Ersatz für den Install-Test im PR — der bleibt die Absicherung gegen das, was ein PR selbst kaputt macht. Hier geht es um das, was ohne einen PR kaputt geht: die Umgebung unter einem unveränderten Chart.
Freigegeben (Betreuer: „Starte mit #52"). Die im Issue-Text offenen Punkte sind damit entschieden.
1. Kein zweiter Install-Test, sondern ein geteilter
Der Rundumtest wird nicht als eigenständiger Job mit kopierter Runner-Einrichtung gebaut. Der bestehende Install-Test-Job wandert in einen wiederverwendbaren Workflow (
workflow_call), den beide aufrufen: die PR-Prüfung wie heute und der neue Rundumtest.Begründung ist dieselbe, mit der die Ausschlussliste genau einen Parser hat: Eine zweite Kopie ist eine zweite Gelegenheit, anders zu prüfen — und zwar unbemerkt. Die fragilen Teile (gepinntes
kubectlsamt Versionsabstands-Prüfung,envsubst, Erkennung des Auftragscontainers, Cluster-Name je Matrix-Zweig) sind genau die, deren Auseinanderlaufen niemandem auffällt, bis ein Ergebnis etwas anderes bedeutet als gedacht.2. Ein Cluster je Chart, keine Wiederverwendung
Auch wenn es Zeit spart: Ein wiederverwendeter Cluster ändert, was der Test beweist — Reste der Vorinstallation, gefüllte Abbild-Zwischenspeicher, bereits angelegte Fixtures. Der Test soll weiterhin „aus dem Nichts hochgekommen" heißen.
3. Nur manuell, mit optionaler Einschränkung
workflow_dispatch, kein Zeitplan — er kostet sonst täglich Rechenzeit für eine Frage, die sich selten ändert. Dazu eine optionale Eingabe für eine Teilmenge von Charts (leer = alle). Die ist kein Luxus: Genau damit lässt sich ein einzelnes Chart gegen den Runner prüfen, wie es #51 gerade braucht.4. Das Ergebnis wird festgehalten
In das Job-Summary gehören Datum, Runner-Kennung,
K3S_IMAGE,kubectl-Version und das Ergebnis je Chart. Ein grüner Lauf, den niemand notiert, ist beim nächsten Mal wieder unbekannt — und die Frage lautet ja gerade „hat sich die Umgebung geändert".5. Ausschlussliste weiterhin über den einen Parser
ci/run-install-test.sh --list-excludedbleibt die einzige Stelle, die das Format liest. Die ausgeschlossenen Charts erscheinen mit ihrer Begründung im Summary, wie in der PR-Prüfung.6. Erwartete Laufzeit als Vergleichswert
#48 hat 20 Charts in 12m41s in einem Job geschafft. Das gehört als Erwartungswert in die Dokumentation, damit eine spätere Abweichung als solche sichtbar ist.
7. Was dieser PR nicht beweisen kann — ausdrücklich so zu benennen
Keiner der beiden Pfade ist im PR selbst prüfbar:
workflow_dispatch-Workflow ist erst auslösbar, wenn er auf dem Standard-Zweig liegt. Der erste echte Rundumtest läuft also nach dem Merge.Beides ist hinzunehmen, weil die Fehlerform laut ist: Bricht der Umbau die PR-Prüfung, geht der nächste Chart-PR rot, nicht still grün. Das gehört in die PR-Beschreibung, in diesen Worten, und nicht als Nebensatz.
8. Dokumentation
README (Abschnitt zur CI) und die Wiki-Seite
CI-CD: was der Rundumtest ist, wann man ihn fährt — nach Änderungen am Runner, amK3S_IMAGE, am gepinntenkubectl, nach einem Umzug —, und dass er den gleichen Job fährt wie die PR-Prüfung, nur mit anderer Matrix.