Veröffentlichte Chart-Version kann still überschrieben werden — der Versions-Check prüft nur gegen main #8

New Issue

2026-09-16T16:03:22+02:00

jlab-bot commented

2026-09-16 16:03:22 +02:00

Migriert aus jk-cluster/helm-charts#160 — urspruenglich angelegt von MeepMr am 2026-08-24.

Verweise der Form #123 im folgenden Text beziehen sich auf die GitHub-Nummerierung, nicht auf die Nummern in diesem Repo. Geschlossene Issues wurden nicht mitgezogen und sind weiterhin nur auf GitHub lesbar.

Eine bereits veröffentlichte Chart-Version kann erneut veröffentlicht und damit in der Registry ersetzt werden, ohne dass eine Prüfung im Repo anschlägt. Der Tag bleibt derselbe, sein Inhalt ändert sich.

Was verifiziert ist

Der Versions-Check in .github/workflows/validate-charts.yml vergleicht ausschliesslich gegen den Zielzweig:

if [ -z "$BASE_VERSION" ]; then
  echo "New chart (does not exist on ${{ github.base_ref }}) …"
elif [ "$BASE_VERSION" = "$NEW_VERSION" ]; then
  echo "::error …was modified but its version was not bumped…"
  exit 1
fi

Er schlägt an, wenn die Version gegenüber main unverändert ist. Die Registry kommt darin nicht vor. Eine Version, die früher aus einem anderen Verzeichniszustand veröffentlicht wurde, ist für diese Prüfung unsichtbar — gegen main sieht sie wie ein normaler Sprung aus.

Wo das praktisch greift

Bei minecraft-server, weil sich dort drei Java-Linien ein Verzeichnis teilen (siehe #158). Konkret in der laufenden #99-Runde:

4.0.0+up2026.8.2.java21 veröffentlicht (PR #156)
4.0.0+up2026.8.2.java8 veröffentlicht (PR #159)
4.0.0+up2026.8.2.java17 folgt
Rückstellung auf java21

Würde Schritt 4 wieder 4.0.0+up2026.8.2.java21 tragen, wäre die Version aus Schritt 1 erneut veröffentlicht — gegen main (dann java17) sähe der Check einen sauberen Sprung und liesse es durch. Deshalb trägt Schritt 4 4.0.1.

Dass es diesmal auffiel, war kein Verdienst der Pipeline: Der Entwicklungs-Agent hat es beim Vorbereiten von Schritt 4 gemeldet.

Was noch zu klären ist

Ob die Registry das Überschreiben tatsächlich zulässt, ist nicht verifiziert — das hängt an ihrer Konfiguration, nicht am Repo. Zwei mögliche Ausgänge, beide handlungsleitend:

Die Registry lehnt ab. Dann scheitert die Veröffentlichung nach dem Merge, also zu einem Zeitpunkt, an dem die Änderung bereits auf main liegt. Die Pipeline meldet einen Fehlschlag, aber erst nach dem Punkt, an dem er billig zu beheben gewesen wäre.
Die Registry überschreibt. Dann ändert ein unveränderter Tag still seinen Inhalt. Wer die Version gepinnt hat, bekommt beim nächsten Abruf etwas anderes als beim letzten — ohne dass irgendwo etwas anders aussieht.

Der erste Schritt ist deshalb, das zu beantworten, nicht sofort einen Check zu bauen.

Vorschlag

Klären, wie sich die Registry bei einem existierenden Tag verhält.
Den Versions-Check um eine Abfrage gegen die Registry ergänzen: Existiert der zu veröffentlichende Tag dort bereits, schlägt der PR fehl — vor dem Merge statt danach.
Falls die Registry Unveränderlichkeit anbietet, sie einschalten. Das ist die Absicherung, die auch dann trägt, wenn jemand ausserhalb der Pipeline veröffentlicht.

Herkunft

Gefunden beim Vorbereiten von Schritt 4 der #99-Runde für minecraft-server. Die Lücke im Check ist im Workflow nachgelesen und bestätigt; das Registry-Verhalten ist ausdrücklich noch offen. Verwandt mit #158 — dort geht es um die Drift zwischen den Linien, hier um die Folge für die Veröffentlichung.

> Migriert aus [`jk-cluster/helm-charts#160`](https://github.com/jk-cluster/helm-charts/issues/160) — urspruenglich angelegt von **MeepMr** am 2026-08-24. > > Verweise der Form `#123` im folgenden Text beziehen sich auf die **GitHub-Nummerierung**, nicht auf die Nummern in diesem Repo. Geschlossene Issues wurden nicht mitgezogen und sind weiterhin nur auf GitHub lesbar. --- Eine bereits veröffentlichte Chart-Version kann erneut veröffentlicht und damit in der Registry ersetzt werden, ohne dass eine Prüfung im Repo anschlägt. Der Tag bleibt derselbe, sein Inhalt ändert sich. ## Was verifiziert ist Der Versions-Check in `.github/workflows/validate-charts.yml` vergleicht ausschliesslich gegen den Zielzweig: ```sh if [ -z "$BASE_VERSION" ]; then echo "New chart (does not exist on ${{ github.base_ref }}) …" elif [ "$BASE_VERSION" = "$NEW_VERSION" ]; then echo "::error …was modified but its version was not bumped…" exit 1 fi ``` Er schlägt an, wenn die Version gegenüber `main` **unverändert** ist. **Die Registry kommt darin nicht vor.** Eine Version, die früher aus einem anderen Verzeichniszustand veröffentlicht wurde, ist für diese Prüfung unsichtbar — gegen `main` sieht sie wie ein normaler Sprung aus. ## Wo das praktisch greift Bei `minecraft-server`, weil sich dort drei Java-Linien **ein** Verzeichnis teilen (siehe #158). Konkret in der laufenden #99-Runde: 1. `4.0.0+up2026.8.2.java21` veröffentlicht (PR #156) 2. `4.0.0+up2026.8.2.java8` veröffentlicht (PR #159) 3. `4.0.0+up2026.8.2.java17` folgt 4. Rückstellung auf java21 Würde Schritt 4 wieder `4.0.0+up2026.8.2.java21` tragen, wäre die Version aus Schritt 1 **erneut veröffentlicht** — gegen `main` (dann java17) sähe der Check einen sauberen Sprung und liesse es durch. Deshalb trägt Schritt 4 `4.0.1`. Dass es diesmal auffiel, war kein Verdienst der Pipeline: Der Entwicklungs-Agent hat es beim Vorbereiten von Schritt 4 gemeldet. ## Was noch zu klären ist Ob die Registry das Überschreiben tatsächlich zulässt, ist **nicht** verifiziert — das hängt an ihrer Konfiguration, nicht am Repo. Zwei mögliche Ausgänge, beide handlungsleitend: - **Die Registry lehnt ab.** Dann scheitert die Veröffentlichung nach dem Merge, also zu einem Zeitpunkt, an dem die Änderung bereits auf `main` liegt. Die Pipeline meldet einen Fehlschlag, aber erst nach dem Punkt, an dem er billig zu beheben gewesen wäre. - **Die Registry überschreibt.** Dann ändert ein unveränderter Tag still seinen Inhalt. Wer die Version gepinnt hat, bekommt beim nächsten Abruf etwas anderes als beim letzten — ohne dass irgendwo etwas anders aussieht. **Der erste Schritt ist deshalb, das zu beantworten**, nicht sofort einen Check zu bauen. ## Vorschlag 1. Klären, wie sich die Registry bei einem existierenden Tag verhält. 2. Den Versions-Check um eine Abfrage gegen die Registry ergänzen: Existiert der zu veröffentlichende Tag dort bereits, schlägt der PR fehl — **vor** dem Merge statt danach. 3. Falls die Registry Unveränderlichkeit anbietet, sie einschalten. Das ist die Absicherung, die auch dann trägt, wenn jemand ausserhalb der Pipeline veröffentlicht. ## Herkunft Gefunden beim Vorbereiten von Schritt 4 der #99-Runde für `minecraft-server`. Die Lücke im Check ist im Workflow nachgelesen und bestätigt; das Registry-Verhalten ist ausdrücklich noch offen. Verwandt mit #158 — dort geht es um die Drift zwischen den Linien, hier um die Folge für die Veröffentlichung.

jlab-bot commented

2026-09-16 16:03:22 +02:00

Kommentar von jk-cluster-bot am 2026-09-01 (migriert aus GitHub).

Gemessen im Zuge von #222 / #224: der Umzug auf die klassische, index-basierte Helm-Registry schließt dieses Issue nicht.

Gitea 1.24.7, sauberes Experiment mit zwei inhaltlich verschiedenen Paketen derselben Version 1.0.0+up7:

1. Upload (description=FIRST):   HTTP 201  exit=0
2. Upload (description=SECOND):  HTTP 201  exit=0

index.yaml sagt:                       description: FIRST
Das .tgz, das die Registry ausliefert: description: SECOND

Die Registry weist einen Republish also nicht ab, sondern nimmt ihn still an und ersetzt das Artefakt — letzter Upload gewinnt. Zusätzlich neu: die Index-Metadaten bleiben beim ersten Upload stehen (description, created), während der Blob getauscht wird. Index und ausgeliefertes Artefakt gehen dabei auseinander.

Der Bump-Check in validate-charts.yml bleibt damit die einzige Schranke gegen ein stilles Überschreiben.

> Kommentar von **jk-cluster-bot** am 2026-09-01 (migriert aus GitHub). --- Gemessen im Zuge von #222 / #224: der Umzug auf die klassische, index-basierte Helm-Registry schließt dieses Issue **nicht**. Gitea 1.24.7, sauberes Experiment mit zwei inhaltlich verschiedenen Paketen derselben Version `1.0.0+up7`: ``` 1. Upload (description=FIRST): HTTP 201 exit=0 2. Upload (description=SECOND): HTTP 201 exit=0 index.yaml sagt: description: FIRST Das .tgz, das die Registry ausliefert: description: SECOND ``` Die Registry weist einen Republish also nicht ab, sondern nimmt ihn still an und ersetzt das Artefakt — letzter Upload gewinnt. Zusätzlich neu: die **Index-Metadaten bleiben beim ersten Upload stehen** (`description`, `created`), während der Blob getauscht wird. Index und ausgeliefertes Artefakt gehen dabei auseinander. Der Bump-Check in `validate-charts.yml` bleibt damit die einzige Schranke gegen ein stilles Überschreiben.

jlab-bot commented

2026-09-16 16:03:23 +02:00

Kommentar von jk-cluster-bot am 2026-09-01 (migriert aus GitHub).

Ergänzend zur Messung oben: der Registry-Umzug (#222) bleibt bewusst bei der klassischen HTTPS-Registry.

Die OCI-Variante derselben Gitea-Instanz wurde dagegen abgewogen. Sie wäre billiger gewesen — der Publish-Workflow bliebe unverändert, helm push scheitert von sich aus laut, und die Cluster-Referenzen behielten die oci://-Form, die sie heute schon haben. Für dieses Issue hätte sie allerdings nichts gebessert: still überschrieben wird dort ebenso, genau deshalb existiert #160. Den Ausschlag für die klassische Registry gab die Darstellung in Giteas Oberfläche — Helm-Pakete mit Versionsliste statt Container-Pakete.

Damit hängt dieses Issue an einer Bedingung. Es bleibt bei HTTPS, bis Gitea hier ein besseres Verhalten mitbringt. Sobald eine Gitea-Version den Republish einer bestehenden Version ablehnt — oder wenigstens Index-Metadaten und ausgeliefertes Artefakt konsistent hält — sind sowohl dieses Issue als auch die Wahl der Registry-Form neu zu bewerten.

Der Befund oben ist an Gitea 1.24.7 gemessen; für andere Hauptversionen gilt er nicht automatisch, insbesondere nicht für die Zielinstanz, solange dort nichts nachgemessen wurde.

> Kommentar von **jk-cluster-bot** am 2026-09-01 (migriert aus GitHub). --- Ergänzend zur Messung oben: der Registry-Umzug (#222) bleibt bewusst bei der klassischen HTTPS-Registry. Die OCI-Variante derselben Gitea-Instanz wurde dagegen abgewogen. Sie wäre billiger gewesen — der Publish-Workflow bliebe unverändert, `helm push` scheitert von sich aus laut, und die Cluster-Referenzen behielten die `oci://`-Form, die sie heute schon haben. Für dieses Issue hätte sie allerdings nichts gebessert: still überschrieben wird dort ebenso, genau deshalb existiert #160. Den Ausschlag für die klassische Registry gab die Darstellung in Giteas Oberfläche — Helm-Pakete mit Versionsliste statt Container-Pakete. **Damit hängt dieses Issue an einer Bedingung.** Es bleibt bei HTTPS, bis Gitea hier ein besseres Verhalten mitbringt. Sobald eine Gitea-Version den Republish einer bestehenden Version ablehnt — oder wenigstens Index-Metadaten und ausgeliefertes Artefakt konsistent hält — sind sowohl dieses Issue als auch die Wahl der Registry-Form neu zu bewerten. Der Befund oben ist an Gitea **1.24.7** gemessen; für andere Hauptversionen gilt er nicht automatisch, insbesondere nicht für die Zielinstanz, solange dort nichts nachgemessen wurde.

jlab-bot commented

2026-09-16 16:03:23 +02:00

Kommentar von jk-cluster-bot am 2026-09-02 (migriert aus GitHub).

Nachgemessen an der produktiven Instanz (Gitea 1.27.0)

Der Befund oben stammt aus einem Testcontainer mit 1.24.7. Die produktive Instanz läuft 1.27.0, drei Minor-Versionen weiter — und gerade am Paket-Verhalten hat sich bei Gitea zuletzt viel getan. Deshalb nachgemessen.

Aufbau: apache-tika in 10.0.1+up3.3.1.0.full ein zweites Mal veröffentlicht, per workflow_dispatch vom unveränderten main. Identischer Quellstand, also kein Risiko, etwas kaputtzumachen.

Ergebnis: der Republish wird angenommen. Dieses Issue bleibt offen.

	vorher	nachher
Lauf	—	erfolgreich, auch der Upload-Schritt
Größe	8267	8267
sha256	`bc64713af2a2284f…`	`2f5fe8c009b70506d…`
`created` (Paket-API)	2026-09-01T18:23:29+02:00	2026-09-01T18:23:29+02:00
`created` (index.yaml)	2026-09-01T18:23:29+02:00	2026-09-01T18:23:29+02:00

Das Artefakt wurde also ersetzt, der Zeitstempel nicht. Die Pipeline blieb grün.

Zwei Korrekturen an der Beschreibung von 1.24.7

Erstens, entwarnend: von „Index und ausgeliefertes Artefakt gehen auseinander" bleibt auf 1.27.0 weniger übrig als befürchtet. Giteas erzeugter Helm-Index enthält überhaupt kein digest-Feld, es kann dort also nichts veralten; und die von der API gemeldete Prüfsumme stimmt mit dem tatsächlich heruntergeladenen Artefakt überein (beide 2f5fe8c0…). Integritätsseitig ist nichts inkonsistent. Was lügt, ist ausschließlich der Zeitstempel.

Zweitens, verschärfend: identischer Quellstand ergibt ein byte-verschiedenes Paket. helm package schreibt Zeitstempel in tar und gzip, ist also nicht reproduzierbar — gleiche Größe, andere Prüfsumme. Damit lässt sich ein stiller Überschreibvorgang nicht durch Nachbauen und Vergleichen erkennen, und das einzige Feld, das ihn verraten würde — created — ist genau das, welches eingefroren bleibt.

Folge

Die an dieses Issue geknüpfte Bedingung — bei HTTPS bleiben, bis Gitea beim Republish ein besseres Verhalten mitbringt — ist auf 1.27.0 nicht erfüllt. Die Entscheidung bleibt damit unverändert bestehen, steht jetzt aber auf der Version, die tatsächlich läuft, statt auf einer Testinstallation.

> Kommentar von **jk-cluster-bot** am 2026-09-02 (migriert aus GitHub). --- ## Nachgemessen an der produktiven Instanz (Gitea 1.27.0) Der Befund oben stammt aus einem Testcontainer mit **1.24.7**. Die produktive Instanz läuft **1.27.0**, drei Minor-Versionen weiter — und gerade am Paket-Verhalten hat sich bei Gitea zuletzt viel getan. Deshalb nachgemessen. **Aufbau:** `apache-tika` in `10.0.1+up3.3.1.0.full` ein zweites Mal veröffentlicht, per `workflow_dispatch` vom unveränderten `main`. Identischer Quellstand, also kein Risiko, etwas kaputtzumachen. **Ergebnis: der Republish wird angenommen. Dieses Issue bleibt offen.** | | vorher | nachher | |---|---|---| | Lauf | — | erfolgreich, auch der Upload-Schritt | | Größe | 8267 | 8267 | | sha256 | `bc64713af2a2284f…` | `2f5fe8c009b70506d…` | | `created` (Paket-API) | 2026-09-01T18:23:29+02:00 | **2026-09-01T18:23:29+02:00** | | `created` (index.yaml) | 2026-09-01T18:23:29+02:00 | **2026-09-01T18:23:29+02:00** | Das Artefakt wurde also ersetzt, der Zeitstempel nicht. Die Pipeline blieb grün. ### Zwei Korrekturen an der Beschreibung von 1.24.7 **Erstens, entwarnend:** von „Index und ausgeliefertes Artefakt gehen auseinander" bleibt auf 1.27.0 weniger übrig als befürchtet. Giteas erzeugter Helm-Index enthält **überhaupt kein `digest`-Feld**, es kann dort also nichts veralten; und die von der API gemeldete Prüfsumme stimmt mit dem tatsächlich heruntergeladenen Artefakt überein (beide `2f5fe8c0…`). Integritätsseitig ist nichts inkonsistent. Was lügt, ist ausschließlich der Zeitstempel. **Zweitens, verschärfend:** identischer Quellstand ergibt ein **byte-verschiedenes Paket**. `helm package` schreibt Zeitstempel in tar und gzip, ist also nicht reproduzierbar — gleiche Größe, andere Prüfsumme. Damit lässt sich ein stiller Überschreibvorgang nicht durch Nachbauen und Vergleichen erkennen, und das einzige Feld, das ihn verraten würde — `created` — ist genau das, welches eingefroren bleibt. ### Folge Die an dieses Issue geknüpfte Bedingung — bei HTTPS bleiben, bis Gitea beim Republish ein besseres Verhalten mitbringt — ist auf **1.27.0 nicht erfüllt**. Die Entscheidung bleibt damit unverändert bestehen, steht jetzt aber auf der Version, die tatsächlich läuft, statt auf einer Testinstallation.

jlab-bot referenced this issue

2026-09-16 16:04:27 +02:00

Repository, Workflows und Issues nach Gitea (JLab-Git) umziehen #14

jlab-bot closed this issue

2026-10-02 21:00:22 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: jlab-cluster/helm-charts#8