fix: awk-Range-Pattern liefert immer leeren Release-Body (jeder Forgejo-Release betroffen) #1

Closed
opened 2026-06-01 23:46:37 +02:00 by holm · 2 comments
Owner
Dimension Bewertung Einschätzung
Aufwand ██░░░░░░░░ Niedrig — awk-Pattern in einer Zeile fixen
Nutzen █████████░ Sehr hoch — Release-Body ist das, was Anwender im Forgejo-Release-View lesen
Bruchhäufigkeit ██████████ Maximal — jeder Release ist betroffen, immer
Nachhaltigkeit █████████░ Sehr hoch — einmal gefixt, dauerhaft sauber
Dringlichkeit ███████░░░ Hoch — jeder weitere Release leidet darunter

Problem

release.sh Zeile 56 (vor dem Forgejo-Release-POST):

notes="$(awk "/^## \\[${next#v}\\]/,/^## \\[/" CHANGELOG.md | sed '$d')"

Der awk-Range-Operator /start/,/end/ matched inklusive Start- und End-Zeile. Die Start-Zeile ist ## [0.1.0] – 2026-06-01, die End-Pattern ist ^## \[ — beide Patterns matchen dieselbe Zeile (die Start-Zeile). awk gibt also nur diese eine Zeile aus, sed '$d' löscht sie wieder → notes ist leer.

Konsequenz: Jeder Forgejo-Release-Eintrag wird mit leerem Body angelegt (HTTP 200, aber body_len: 0). Anwender, die auf den Release-View gehen, sehen nur den Tag-Namen, keine Changelog-Notes.

Reproduktion

In jedem Repo mit CHANGELOG.md:

next="v0.1.0"
awk "/^## \\[${next#v}\\]/,/^## \\[/" CHANGELOG.md
# → liefert nur die erste Zeile, nicht die ganze Sektion

Fix-Vorschlag

awk mit Flag-Variable statt Range:

notes="$(awk -v ver="${next#v}" '
  $0 ~ "^## \\["ver"\\]" {flag=1; next}
  /^## \[/                 {flag=0}
  /^<!-- generated/        {flag=0}
  flag
' CHANGELOG.md)"
  • Startet das Sammeln nach der Versions-Header-Zeile (next skipt sie)
  • Stoppt bei nächster Versions-Header-Zeile ODER beim git-cliff-Footer
  • Keine Inklusiv-Falle, kein nachträgliches sed '$d' mehr nötig

Acceptance

  • Test in einem Repo mit CHANGELOG: notes enthält die komplette Section minus den Header
  • Forgejo-Release-Body nach API-POST: body_len > 0, enthält die Listen-Einträge
  • Verifiziert mit z.B. holm.tools.secret/mikrotik-captive-demo v0.1.0 (manuell via PATCH gefixt am 2026-06-01)

Hinweis zum Forgejo-is_empty-Quirk

Beim Erst-Release in einem mit auto_init=false angelegten Repo schlägt der Release-POST mit HTTP 422 „repo is empty" fehl (is_empty-Quirk-Memory — Workaround: Repo einmal in Web-UI öffnen oder Template-Repo verwenden). Dieser Bug ist separat vom awk-Bug, aber tritt oft zusammen auf, weil der erste Release häufig der erste API-Call ist.

| Dimension | Bewertung | Einschätzung | |---|---|---| | Aufwand | `██░░░░░░░░` | Niedrig — awk-Pattern in einer Zeile fixen | | Nutzen | `█████████░` | Sehr hoch — Release-Body ist das, was Anwender im Forgejo-Release-View lesen | | Bruchhäufigkeit | `██████████` | Maximal — jeder Release ist betroffen, immer | | Nachhaltigkeit | `█████████░` | Sehr hoch — einmal gefixt, dauerhaft sauber | | Dringlichkeit | `███████░░░` | Hoch — jeder weitere Release leidet darunter | ## Problem `release.sh` Zeile 56 (vor dem Forgejo-Release-POST): ```bash notes="$(awk "/^## \\[${next#v}\\]/,/^## \\[/" CHANGELOG.md | sed '$d')" ``` Der awk-Range-Operator `/start/,/end/` matched **inklusive Start- und End-Zeile**. Die Start-Zeile ist `## [0.1.0] – 2026-06-01`, die End-Pattern ist `^## \[` — beide Patterns matchen **dieselbe Zeile** (die Start-Zeile). awk gibt also nur diese eine Zeile aus, `sed '$d'` löscht sie wieder → `notes` ist leer. **Konsequenz:** Jeder Forgejo-Release-Eintrag wird mit leerem Body angelegt (HTTP 200, aber `body_len: 0`). Anwender, die auf den Release-View gehen, sehen nur den Tag-Namen, keine Changelog-Notes. ## Reproduktion In jedem Repo mit CHANGELOG.md: ```bash next="v0.1.0" awk "/^## \\[${next#v}\\]/,/^## \\[/" CHANGELOG.md # → liefert nur die erste Zeile, nicht die ganze Sektion ``` ## Fix-Vorschlag `awk` mit Flag-Variable statt Range: ```bash notes="$(awk -v ver="${next#v}" ' $0 ~ "^## \\["ver"\\]" {flag=1; next} /^## \[/ {flag=0} /^<!-- generated/ {flag=0} flag ' CHANGELOG.md)" ``` - Startet das Sammeln **nach** der Versions-Header-Zeile (`next` skipt sie) - Stoppt bei nächster Versions-Header-Zeile ODER beim git-cliff-Footer - Keine Inklusiv-Falle, kein nachträgliches `sed '$d'` mehr nötig ## Acceptance - Test in einem Repo mit CHANGELOG: `notes` enthält die komplette Section minus den Header - Forgejo-Release-Body nach API-POST: `body_len > 0`, enthält die Listen-Einträge - Verifiziert mit z.B. `holm.tools.secret/mikrotik-captive-demo` v0.1.0 (manuell via PATCH gefixt am 2026-06-01) ## Hinweis zum Forgejo-`is_empty`-Quirk Beim Erst-Release in einem mit `auto_init=false` angelegten Repo schlägt der Release-POST mit HTTP 422 „repo is empty" fehl ([is_empty-Quirk-Memory](https://forgejo.mueller.network/) — Workaround: Repo einmal in Web-UI öffnen oder Template-Repo verwenden). Dieser Bug ist **separat** vom awk-Bug, aber tritt oft zusammen auf, weil der erste Release häufig der erste API-Call ist.
Author
Owner

Weiterhin aktuell (2026-09-23, nixos.fleet): Releases v0.27.3, v1.0.0, v1.0.1, v1.1.0, v1.2.0 haben alle body = 0 Zeichen. Der v1.2.0-Text wurde per API-PATCH nachgetragen, mit

notes="$(awk -v h="## [${next#v}]" 'index($0,h)==1 {on=1; print; next} on && /^## \[/ {exit} on {print}' CHANGELOG.md)"

(an nixos.fleet/CHANGELOG.md getestet: 14 Zeilen für 1.2.0). Zusätzlich: der POST für v1.2.0 lief einmal mit HTTP 500 ins Leere — das Script meldet „released" schon vorher, curl -f bricht ab, ohne „published"; Wiederholung ergab 201. Dublette #4 geschlossen.

🤖 angelegt von Claude v00 (API/Token holm)

Weiterhin aktuell (2026-09-23, nixos.fleet): Releases v0.27.3, v1.0.0, v1.0.1, v1.1.0, v1.2.0 haben alle `body` = 0 Zeichen. Der v1.2.0-Text wurde per API-PATCH nachgetragen, mit ```bash notes="$(awk -v h="## [${next#v}]" 'index($0,h)==1 {on=1; print; next} on && /^## \[/ {exit} on {print}' CHANGELOG.md)" ``` (an nixos.fleet/CHANGELOG.md getestet: 14 Zeilen für 1.2.0). Zusätzlich: der POST für v1.2.0 lief einmal mit HTTP 500 ins Leere — das Script meldet „released" schon vorher, `curl -f` bricht ab, ohne „published"; Wiederholung ergab 201. Dublette #4 geschlossen. > 🤖 angelegt von Claude v00 (API/Token holm)
Author
Owner

Behoben in 7f5c48b (Merge 9d57973 auf dev), gepusht; ~/bin/release zeigt auf diesen Working-Tree, wirkt also ab dem nächsten Release.

Beleg vor dem Fix (frisch, 2026-09-24): die unveränderte Zeile 104 liefert für nixos.fleet v1.2.0/v1.1.0, release v0.1.1 und eine Minimal-CHANGELOG jeweils 0 Zeilen; der awk-Bereich allein gibt nur die Überschrift aus, sed $d löscht sie. API: alle nixos.fleet-Releases v0.27.3–v1.2.0 mit leerem body.

Beleg nach dem Fix (echter Block aus release.sh herausgeschnitten und ausgeführt): v1.2.0 → 13 Zeilen, v1.1.0 → 20, release v0.1.1 → 5, unbekannte Version → 0. bash -n ok.

Nicht umgesetzt: Release-Texte alter Tags nachtragen (nur nixos.fleet v1.2.0 per PATCH nachgetragen).

🤖 angelegt von Claude v00 (API/Token holm)

Behoben in 7f5c48b (Merge 9d57973 auf dev), gepusht; `~/bin/release` zeigt auf diesen Working-Tree, wirkt also ab dem nächsten Release. Beleg vor dem Fix (frisch, 2026-09-24): die unveränderte Zeile 104 liefert für nixos.fleet v1.2.0/v1.1.0, release v0.1.1 und eine Minimal-CHANGELOG jeweils 0 Zeilen; der awk-Bereich allein gibt nur die Überschrift aus, `sed $d` löscht sie. API: alle nixos.fleet-Releases v0.27.3–v1.2.0 mit leerem body. Beleg nach dem Fix (echter Block aus release.sh herausgeschnitten und ausgeführt): v1.2.0 → 13 Zeilen, v1.1.0 → 20, release v0.1.1 → 5, unbekannte Version → 0. `bash -n` ok. Nicht umgesetzt: Release-Texte alter Tags nachtragen (nur nixos.fleet v1.2.0 per PATCH nachgetragen). > 🤖 angelegt von Claude v00 (API/Token holm)
holm closed this issue 2026-09-24 00:12:20 +02:00
Sign in to join this conversation.
No description provided.