⚙️ 🤖 release.sh: Forgejo-Release-POST scheitert mit HTTP 500 (nixos.fleet 2×) #5

New issue

Open

opened 2026-09-25 13:58:10 +02:00 by holm · 1 comment

holm commented

2026-09-25 13:58:10 +02:00

Owner

Dimension	Bewertung	Einschätzung
Aufwand	`███░░░░░░░`	Gering bis mittel — Ursache unbekannt, Retry/Meldung einfach
Nutzen	`█████░░░░░`	Mittel — Release erscheint sonst gar nicht auf Forgejo
Bruchhäufigkeit	`██████░░░░`	nixos.fleet 2 von 2 Releases (v1.2.0, v1.3.0)
Nachhaltigkeit	`███████░░░`	Hoch, sobald die Ursache feststeht
Dringlichkeit	`███░░░░░░░`	Niedrig — Tag und CHANGELOG stimmen, Release per API nachholbar

Befund

~/bin/release --yes in holm.dotfiles.secret/nixos.fleet:

v1.2.0 (2026-09-23) und v1.3.0 (2026-09-25): Schritt 8 (POST /releases) → curl: (22) … error: 500. Tag und Push waren schon erfolgt, das Script hatte „✅ released" gemeldet; „✅ forgejo release … published" fehlt.
Jeweils sofort danach derselbe POST von Hand (gleicher Token, gleiche Payload-Form, Notizen per korrigiertem awk) → HTTP 201.
Im selben Zeitraum bei Zentonic/ripgrepgeneric v1.2.0: POST sofort 201.

Hypothese (ungeprüft)

Der POST folgt unmittelbar auf git push --tags; Forgejo hat den neuen Tag im großen Repo (nixos.fleet) evtl. noch nicht verarbeitet → 500. Dafür spricht: Wiederholung Sekunden später klappt, kleines Repo klappt sofort.

Vorschlag

POST bei 5xx 2–3× mit kurzer Pause wiederholen; bei endgültigem Fehler „❌ forgejo release fehlt — nachholen mit …" statt stillem Abbruch. Verwandt: #3 (Push-Fehler wird verschluckt).

🤖 angelegt von Claude v00 (API/Token holm)

| Dimension | Bewertung | Einschätzung | |---|---|---| | Aufwand | `███░░░░░░░` | Gering bis mittel — Ursache unbekannt, Retry/Meldung einfach | | Nutzen | `█████░░░░░` | Mittel — Release erscheint sonst gar nicht auf Forgejo | | Bruchhäufigkeit | `██████░░░░` | nixos.fleet 2 von 2 Releases (v1.2.0, v1.3.0) | | Nachhaltigkeit | `███████░░░` | Hoch, sobald die Ursache feststeht | | Dringlichkeit | `███░░░░░░░` | Niedrig — Tag und CHANGELOG stimmen, Release per API nachholbar | ## Befund `~/bin/release --yes` in holm.dotfiles.secret/nixos.fleet: - v1.2.0 (2026-09-23) und v1.3.0 (2026-09-25): Schritt 8 (POST `/releases`) → `curl: (22) … error: 500`. Tag und Push waren schon erfolgt, das Script hatte „✅ released" gemeldet; „✅ forgejo release … published" fehlt. - Jeweils sofort danach derselbe POST von Hand (gleicher Token, gleiche Payload-Form, Notizen per korrigiertem awk) → **HTTP 201**. - Im selben Zeitraum bei Zentonic/ripgrepgeneric v1.2.0: POST sofort 201. ## Hypothese (ungeprüft) Der POST folgt unmittelbar auf `git push --tags`; Forgejo hat den neuen Tag im großen Repo (nixos.fleet) evtl. noch nicht verarbeitet → 500. Dafür spricht: Wiederholung Sekunden später klappt, kleines Repo klappt sofort. ## Vorschlag POST bei 5xx 2–3× mit kurzer Pause wiederholen; bei endgültigem Fehler „❌ forgejo release fehlt — nachholen mit …" statt stillem Abbruch. Verwandt: #3 (Push-Fehler wird verschluckt). > 🤖 angelegt von Claude v00 (API/Token holm)

holm added the

Kind/Bug

Priority/Low

labels

2026-09-25 13:58:11 +02:00

holm commented

2026-09-25 14:27:29 +02:00

Author

Owner

Datenpunkt 2026-09-25 14:27: nixos.fleet v1.3.1 — POST sofort erfolgreich („✅ forgejo release v1.3.1 published"), kein 500. Also nicht jedes Mal; spricht eher für ein Timing-/Lastproblem als für einen festen Fehler.