Der Release-Job für 8.0.0 (Run 569 auf afd8255) scheiterte im Schritt „Publish the release“ mit curl: Argument list too long (exit 126). Angelegt wurde nichts: kein Tag, kein Release.
Ursache 1 – Argumentgrenze..gitea/workflows/release.yml übergab den JSON-Payload als ein einziges Argument (curl -d "$payload"). Linux begrenzt ein einzelnes Argument auf 128 KiB (MAX_ARG_STRLEN); der 8.0.0-Eintrag in CHANGES.md hatte allein 129 012 Zeichen. Bisher größtes Release war v7.0.0 mit 34 KB.
Ursache 2 – Speichergrenze. Gitea speichert die Release-Notiz in einer TEXT-Spalte; diese Instanz läuft auf MySQL, also höchstens 65 535 Bytes. Selbst mit behobenem Aufruf wäre die Notiz abgewiesen worden.
Warum kein Rerun: Ein Re-run nimmt die Workflow-Datei des gescheiterten Commits; ein neuer Push löst release.yml nur aus, wenn VERSION sich bewegt.
Umgesetzt (2ddcd6b)
release.yml: Payload in /tmp/release-payload.json, gesendet mit --data-binary @….
release.yml: workflow_dispatch: als zweiter Auslöser; die vorhandene Prüfung auf ein schon existierendes Release verhindert weiterhin ein zweites.
release.yml: Der Schritt „Release notes from CHANGES.md“ verweigert ab 60 000 Bytes, bevor ein Tarball gebaut oder ein Tag angelegt wird.
CHANGES.md: Der 8.0.0-Eintrag ist von 129 KB auf 22 KB gekürzt – Kopf, Breaking Changes, Migrationszeile, Bump-Liste und Zusammenfassung unverändert; die 80 Changeset-Abschnitte ersetzt je ein Absatz für die 16 größeren Änderungen, alle übrigen bleiben als Stichpunkt in der Bump-Liste. Wie Einträge grundsätzlich kompakter werden, regelt #184.
DEVELOPMENT.md Schritt 6: die Größengrenze und der Weg nach einem gescheiterten Release-Job (Ursache beheben, publishen, workflow_dispatch auf main).
Akzeptanzkriterien
tools/wikitool version notes | wc -c liegt unter 60 000 (gemessen: 22 043).
CI auf dem Fix-Commit ist grün (Run 570, verify und pwsh).
Der per workflow_dispatch auf main gestartete Release-Lauf (Run 571) ist grün und hat Tag v8.0.0 auf 2ddcd6b und das Release https://gitea.nehmer.net/torben/chemenu/releases/tag/v8.0.0 angelegt; die sechs Asset-Uploads laufen mit curl -f, ein fehlgeschlagener hätte den Job rot gemacht.
Der Tag zeigt auf den Fix-Commit statt auf afd8255; der ausgelieferte Baum unterscheidet sich nur im gekürzten CHANGES.md, weil .gitea/ und DEVELOPMENT.md nicht ausgeliefert werden.
Versions-Teil
Keiner. .gitea/ und DEVELOPMENT.md werden nicht ausgeliefert; die Kürzung von CHANGES.md ist Doku am schon fixierten 8.0.0-Eintrag und gehört in genau dieses Release.
## Befund
Der Release-Job für 8.0.0 (Run 569 auf `afd8255`) scheiterte im Schritt „Publish the release“ mit `curl: Argument list too long` (exit 126). Angelegt wurde nichts: kein Tag, kein Release.
**Ursache 1 – Argumentgrenze.** `.gitea/workflows/release.yml` übergab den JSON-Payload als ein einziges Argument (`curl -d "$payload"`). Linux begrenzt ein einzelnes Argument auf 128 KiB (`MAX_ARG_STRLEN`); der 8.0.0-Eintrag in `CHANGES.md` hatte allein 129 012 Zeichen. Bisher größtes Release war v7.0.0 mit 34 KB.
**Ursache 2 – Speichergrenze.** Gitea speichert die Release-Notiz in einer `TEXT`-Spalte; diese Instanz läuft auf MySQL, also höchstens 65 535 Bytes. Selbst mit behobenem Aufruf wäre die Notiz abgewiesen worden.
**Warum kein Rerun:** Ein Re-run nimmt die Workflow-Datei des gescheiterten Commits; ein neuer Push löst `release.yml` nur aus, wenn `VERSION` sich bewegt.
## Umgesetzt (`2ddcd6b`)
- `release.yml`: Payload in `/tmp/release-payload.json`, gesendet mit `--data-binary @…`.
- `release.yml`: `workflow_dispatch:` als zweiter Auslöser; die vorhandene Prüfung auf ein schon existierendes Release verhindert weiterhin ein zweites.
- `release.yml`: Der Schritt „Release notes from CHANGES.md“ verweigert ab 60 000 Bytes, bevor ein Tarball gebaut oder ein Tag angelegt wird.
- `CHANGES.md`: Der 8.0.0-Eintrag ist von 129 KB auf 22 KB gekürzt – Kopf, Breaking Changes, Migrationszeile, Bump-Liste und Zusammenfassung unverändert; die 80 Changeset-Abschnitte ersetzt je ein Absatz für die 16 größeren Änderungen, alle übrigen bleiben als Stichpunkt in der Bump-Liste. Wie Einträge grundsätzlich kompakter werden, regelt #184.
- `DEVELOPMENT.md` Schritt 6: die Größengrenze und der Weg nach einem gescheiterten Release-Job (Ursache beheben, publishen, `workflow_dispatch` auf `main`).
## Akzeptanzkriterien
- [x] `tools/wikitool version notes | wc -c` liegt unter 60 000 (gemessen: 22 043).
- [x] CI auf dem Fix-Commit ist grün (Run 570, `verify` und `pwsh`).
- [x] Der per `workflow_dispatch` auf `main` gestartete Release-Lauf (Run 571) ist grün und hat Tag `v8.0.0` auf `2ddcd6b` und das Release https://gitea.nehmer.net/torben/chemenu/releases/tag/v8.0.0 angelegt; die sechs Asset-Uploads laufen mit `curl -f`, ein fehlgeschlagener hätte den Job rot gemacht.
Der Tag zeigt auf den Fix-Commit statt auf `afd8255`; der ausgelieferte Baum unterscheidet sich nur im gekürzten `CHANGES.md`, weil `.gitea/` und `DEVELOPMENT.md` nicht ausgeliefert werden.
## Versions-Teil
Keiner. `.gitea/` und `DEVELOPMENT.md` werden nicht ausgeliefert; die Kürzung von `CHANGES.md` ist Doku am schon fixierten 8.0.0-Eintrag und gehört in genau dieses Release.
Changelog: Body in den Endzustand gebracht – Fix in 2ddcd6b, CI grün (Run 570), Release-Lauf per Dispatch grün (Run 571), v8.0.0 veröffentlicht; alle drei Kriterien abgehakt. Geschlossen.
**Changelog:** Body in den Endzustand gebracht – Fix in `2ddcd6b`, CI grün (Run 570), Release-Lauf per Dispatch grün (Run 571), `v8.0.0` veröffentlicht; alle drei Kriterien abgehakt. Geschlossen.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Befund
Der Release-Job für 8.0.0 (Run 569 auf
afd8255) scheiterte im Schritt „Publish the release“ mitcurl: Argument list too long(exit 126). Angelegt wurde nichts: kein Tag, kein Release.Ursache 1 – Argumentgrenze.
.gitea/workflows/release.ymlübergab den JSON-Payload als ein einziges Argument (curl -d "$payload"). Linux begrenzt ein einzelnes Argument auf 128 KiB (MAX_ARG_STRLEN); der 8.0.0-Eintrag inCHANGES.mdhatte allein 129 012 Zeichen. Bisher größtes Release war v7.0.0 mit 34 KB.Ursache 2 – Speichergrenze. Gitea speichert die Release-Notiz in einer
TEXT-Spalte; diese Instanz läuft auf MySQL, also höchstens 65 535 Bytes. Selbst mit behobenem Aufruf wäre die Notiz abgewiesen worden.Warum kein Rerun: Ein Re-run nimmt die Workflow-Datei des gescheiterten Commits; ein neuer Push löst
release.ymlnur aus, wennVERSIONsich bewegt.Umgesetzt (
2ddcd6b)release.yml: Payload in/tmp/release-payload.json, gesendet mit--data-binary @….release.yml:workflow_dispatch:als zweiter Auslöser; die vorhandene Prüfung auf ein schon existierendes Release verhindert weiterhin ein zweites.release.yml: Der Schritt „Release notes from CHANGES.md“ verweigert ab 60 000 Bytes, bevor ein Tarball gebaut oder ein Tag angelegt wird.CHANGES.md: Der 8.0.0-Eintrag ist von 129 KB auf 22 KB gekürzt – Kopf, Breaking Changes, Migrationszeile, Bump-Liste und Zusammenfassung unverändert; die 80 Changeset-Abschnitte ersetzt je ein Absatz für die 16 größeren Änderungen, alle übrigen bleiben als Stichpunkt in der Bump-Liste. Wie Einträge grundsätzlich kompakter werden, regelt #184.DEVELOPMENT.mdSchritt 6: die Größengrenze und der Weg nach einem gescheiterten Release-Job (Ursache beheben, publishen,workflow_dispatchaufmain).Akzeptanzkriterien
tools/wikitool version notes | wc -cliegt unter 60 000 (gemessen: 22 043).verifyundpwsh).workflow_dispatchaufmaingestartete Release-Lauf (Run 571) ist grün und hat Tagv8.0.0auf2ddcd6bund das Release https://gitea.nehmer.net/torben/chemenu/releases/tag/v8.0.0 angelegt; die sechs Asset-Uploads laufen mitcurl -f, ein fehlgeschlagener hätte den Job rot gemacht.Der Tag zeigt auf den Fix-Commit statt auf
afd8255; der ausgelieferte Baum unterscheidet sich nur im gekürztenCHANGES.md, weil.gitea/undDEVELOPMENT.mdnicht ausgeliefert werden.Versions-Teil
Keiner.
.gitea/undDEVELOPMENT.mdwerden nicht ausgeliefert; die Kürzung vonCHANGES.mdist Doku am schon fixierten 8.0.0-Eintrag und gehört in genau dieses Release.Changelog: Body in den Endzustand gebracht – Fix in
2ddcd6b, CI grün (Run 570), Release-Lauf per Dispatch grün (Run 571),v8.0.0veröffentlicht; alle drei Kriterien abgehakt. Geschlossen.