kubectl/k3s-Abstandspruefung laeuft nicht in dem PR, der sie ausloesen wuerde #72

New Issue

2026-10-02T01:33:09+02:00

jlab-bot commented

2026-10-02 01:33:09 +02:00

Die Versionsabstands-Prüfung zwischen kubectl und k3s läuft nicht in dem PR, der sie auslösen würde — sie sitzt in einem Job, der genau dann übersprungen wird.

Der Zustand

In .github/workflows/install-test.yml:

K3S_IMAGE: docker.io/rancher/k3s:v1.35.5-k3s1
# renovate: datasource=github-releases depName=kubernetes/kubernetes
KUBECTL_VERSION: v1.35.5

Die Prüfung („mehr als ein Minor Abstand → Fehler") ist ein Schritt innerhalb des Install-Test-Jobs. Dieser Job läuft nur für Charts, die ein PR ändert. Ein PR, der ausschließlich KUBECTL_VERSION hebt, ändert kein Chart-Verzeichnis — der Job wird übersprungen, die Prüfung findet nicht statt, der PR ist grün.

Was gerade vorliegt

Renovate hat zwei PRs offen, erzeugt durch separateMinorPatch aus Gitea #34:

Patch auf v1.35.9 — unkritisch, Abstand bleibt 0.
Minor auf v1.37.1 — Abstand zu k3s v1.35.5 wäre zwei Minor. Genau der Fall, den die Prüfung abfangen soll.

Beide liefen nur 11 beziehungsweise 12 Sekunden, also ohne Install-Test. Der 1.37.1-PR kann damit grün automerged werden, und rot wird anschließend der nächste Chart-PR — mit einer Meldung über kubectl, in einer Änderung, die niemand damit in Verbindung bringt.

K3S_IMAGE wird von nichts verfolgt. Der Kommentar im Workflow sagt das selbst. Die beiden Werte können also nur auseinanderlaufen, nicht gemeinsam wandern.

Warum das die bekannte Fehlerklasse ist

Die README dieses Repositories formuliert die Regel: eine Prüfung, die ein kaputtes System besteht, ist schlimmer als keine Prüfung. Hier ist es eine Stufe subtiler — die Prüfung besteht nicht, sie findet nicht statt, und die Grünfärbung des PR behauptet trotzdem, es sei alles geprüft. Dass der Fehler später und an anderer Stelle auftaucht, ist der eigentliche Schaden.

Entstanden ist die Lage erst durch die Renovate-Angleichung (#34): Vorher bewegte niemand KUBECTL_VERSION automatisch.

Mögliche Wege, nicht abschließend bewertet

Die Prüfung aus dem Install-Test herausziehen in einen Job, der immer läuft — etwa neben dem Mengen-Render-Test in validate-charts.yml, der bewusst über alle Charts läuft, unabhängig von den geänderten. Dann geht der verursachende PR rot, sofort und mit der richtigen Meldung. Strukturell die richtige Antwort; zu klären ist, wo die beiden Werte dann gelesen werden, ohne sie zu duplizieren.
K3S_IMAGE ebenfalls von Renovate verfolgen lassen (ein # renovate:-Kommentar genügt, die Zeile ist ein Docker-Verweis). Dann wandern beide — aber möglicherweise in zwei PRs, und zwischen den Merges besteht derselbe Zustand.
Beide Aktualisierungen gruppieren (groupName), damit sie nur gemeinsam auftreten. Verträgt sich mit Weg 2 und nimmt das Zwischenfenster weg.
kubectl an die k3s-Linie binden (allowedVersions). Einfach, aber die Grenze muss bei jedem k3s-Sprung von Hand mitwandern — und wer das vergisst, friert kubectl still ein. Dieselbe Falle wie bei der nginx-Einschränkung, die aus genau diesem Grund suffix-tolerant geschrieben wurde.

Weg 1 plus 3 wäre meine Empfehlung: Die Prüfung greift dort, wo die Änderung passiert, und die beiden Werte können sich gar nicht erst trennen.

Sofort, unabhängig von der Lösung

Den PR auf v1.37.1 nicht mergen, solange K3S_IMAGE auf v1.35.5 steht. Der Patch-PR auf v1.35.9 ist unbedenklich.

Die Versionsabstands-Prüfung zwischen `kubectl` und `k3s` **läuft nicht in dem PR, der sie auslösen würde** — sie sitzt in einem Job, der genau dann übersprungen wird. ## Der Zustand In `.github/workflows/install-test.yml`: ``` K3S_IMAGE: docker.io/rancher/k3s:v1.35.5-k3s1 # renovate: datasource=github-releases depName=kubernetes/kubernetes KUBECTL_VERSION: v1.35.5 ``` Die Prüfung („mehr als ein Minor Abstand → Fehler") ist ein **Schritt innerhalb des Install-Test-Jobs**. Dieser Job läuft nur für Charts, die ein PR ändert. Ein PR, der ausschließlich `KUBECTL_VERSION` hebt, ändert kein Chart-Verzeichnis — der Job wird übersprungen, die Prüfung findet nicht statt, der PR ist grün. ## Was gerade vorliegt Renovate hat zwei PRs offen, erzeugt durch `separateMinorPatch` aus Gitea #34: - **Patch auf `v1.35.9`** — unkritisch, Abstand bleibt 0. - **Minor auf `v1.37.1`** — Abstand zu `k3s v1.35.5` wäre **zwei Minor**. Genau der Fall, den die Prüfung abfangen soll. Beide liefen nur 11 beziehungsweise 12 Sekunden, also ohne Install-Test. Der 1.37.1-PR kann damit grün automerged werden, und rot wird anschließend der **nächste Chart-PR** — mit einer Meldung über `kubectl`, in einer Änderung, die niemand damit in Verbindung bringt. **`K3S_IMAGE` wird von nichts verfolgt.** Der Kommentar im Workflow sagt das selbst. Die beiden Werte können also nur auseinanderlaufen, nicht gemeinsam wandern. ## Warum das die bekannte Fehlerklasse ist Die README dieses Repositories formuliert die Regel: *eine Prüfung, die ein kaputtes System besteht, ist schlimmer als keine Prüfung.* Hier ist es eine Stufe subtiler — die Prüfung besteht nicht, sie **findet nicht statt**, und die Grünfärbung des PR behauptet trotzdem, es sei alles geprüft. Dass der Fehler später und an anderer Stelle auftaucht, ist der eigentliche Schaden. Entstanden ist die Lage erst durch die Renovate-Angleichung (#34): Vorher bewegte niemand `KUBECTL_VERSION` automatisch. ## Mögliche Wege, nicht abschließend bewertet 1. **Die Prüfung aus dem Install-Test herausziehen** in einen Job, der immer läuft — etwa neben dem Mengen-Render-Test in `validate-charts.yml`, der bewusst über alle Charts läuft, unabhängig von den geänderten. Dann geht der verursachende PR rot, sofort und mit der richtigen Meldung. Strukturell die richtige Antwort; zu klären ist, wo die beiden Werte dann gelesen werden, ohne sie zu duplizieren. 2. **`K3S_IMAGE` ebenfalls von Renovate verfolgen lassen** (ein `# renovate:`-Kommentar genügt, die Zeile ist ein Docker-Verweis). Dann wandern beide — aber möglicherweise in zwei PRs, und zwischen den Merges besteht derselbe Zustand. 3. **Beide Aktualisierungen gruppieren** (`groupName`), damit sie nur gemeinsam auftreten. Verträgt sich mit Weg 2 und nimmt das Zwischenfenster weg. 4. **`kubectl` an die k3s-Linie binden** (`allowedVersions`). Einfach, aber die Grenze muss bei jedem k3s-Sprung von Hand mitwandern — und wer das vergisst, friert `kubectl` still ein. Dieselbe Falle wie bei der nginx-Einschränkung, die aus genau diesem Grund suffix-tolerant geschrieben wurde. Weg 1 plus 3 wäre meine Empfehlung: Die Prüfung greift dort, wo die Änderung passiert, und die beiden Werte können sich gar nicht erst trennen. ## Sofort, unabhängig von der Lösung **Den PR auf `v1.37.1` nicht mergen**, solange `K3S_IMAGE` auf `v1.35.5` steht. Der Patch-PR auf `v1.35.9` ist unbedenklich.

jlab-bot commented

2026-10-04 21:26:33 +02:00

Nachgeprüft am 2026-10-04: unverändert offen, und hier ist der Beleg

.github/workflows/validate-charts.yml:230-233:

install-test:
  name: "Install-test"
  needs: [detect-changed-charts, build-chart]
  if: needs.detect-changed-charts.outputs.any-install == 'true'

Die Abstandsprüfung lebt innerhalb dieses Jobs. Ein PR, der nur KUBECTL_VERSION in .github/workflows/install-test.yml anhebt, berührt kein Chart-Verzeichnis, also liefert detect-changed-charts eine leere Liste, any-install wird false, der Job wird übersprungen — und die Prüfung läuft genau in dem PR nicht, für den sie gebaut wurde.

Heutiger Stand der beiden Werte: KUBECTL_VERSION: v1.35.9 (durch #68 angehoben) gegen K3S_IMAGE v1.35.5. Gleiche Minor-Version, der Abstand ist also in Ordnung — aber durch Glück, nicht durch Prüfung.

Darum muss PR #69 als WIP stehen: er hebt KUBECTL_VERSION auf v1.37.1, also zwei Minor-Versionen über dem Server. Kubernetes stützt höchstens eine. Der PR wäre grün, weil die Prüfung in ihm nicht läuft.

Nebenbefund: der Kommentar bei install-test.yml:120-121 sagt, der Wert „mirrors K3S_IMAGE above (v1.35.5)". Seit #68 steht dort v1.35.9 — dieselbe Minor-Linie, also harmlos, aber der Kommentar stimmt wörtlich nicht mehr.

## Nachgeprüft am 2026-10-04: unverändert offen, und hier ist der Beleg `.github/workflows/validate-charts.yml:230-233`: ```yaml install-test: name: "Install-test" needs: [detect-changed-charts, build-chart] if: needs.detect-changed-charts.outputs.any-install == 'true' ``` Die Abstandsprüfung lebt **innerhalb** dieses Jobs. Ein PR, der nur `KUBECTL_VERSION` in `.github/workflows/install-test.yml` anhebt, berührt **kein** Chart-Verzeichnis, also liefert `detect-changed-charts` eine leere Liste, `any-install` wird `false`, der Job wird übersprungen — und die Prüfung läuft genau in dem PR nicht, für den sie gebaut wurde. **Heutiger Stand der beiden Werte:** `KUBECTL_VERSION: v1.35.9` (durch #68 angehoben) gegen `K3S_IMAGE` v1.35.5. Gleiche Minor-Version, der Abstand ist also in Ordnung — aber durch Glück, nicht durch Prüfung. **Darum muss PR #69 als WIP stehen:** er hebt `KUBECTL_VERSION` auf `v1.37.1`, also **zwei** Minor-Versionen über dem Server. Kubernetes stützt höchstens eine. Der PR wäre grün, weil die Prüfung in ihm nicht läuft. **Nebenbefund:** der Kommentar bei `install-test.yml:120-121` sagt, der Wert „mirrors K3S_IMAGE above (v1.35.5)". Seit #68 steht dort `v1.35.9` — dieselbe Minor-Linie, also harmlos, aber der Kommentar stimmt wörtlich nicht mehr.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: jlab-cluster/helm-charts#72