Skip to content

Release-Workflow übernimmt den handgeschriebenen Unreleased-Abschnitt - #234

Merged
CallMeTechie merged 2 commits into
masterfrom
fix/changelog-release-consumes-unreleased
Jul 26, 2026
Merged

Release-Workflow übernimmt den handgeschriebenen Unreleased-Abschnitt#234
CallMeTechie merged 2 commits into
masterfrom
fix/changelog-release-consumes-unreleased

Conversation

@CallMeTechie

Copy link
Copy Markdown
Owner

Die Ursache hinter einem Muster, das mir zuletzt bei jedem Merge begegnet ist: handgeschriebene CHANGELOG-Beschreibungen landeten in keinem Release, und die Datei sammelte [Unreleased]-Überschriften an, die längst ausgeliefert waren.

Befund

Der Workflow erzeugt seinen Versionsblock aus der ersten Zeile der letzten Commit-Message und schiebt ihn mit einem awk-Einzeiler ein:

/^# Changelog/ { print; print ""; print block; print ""; print "---"; next }

Ein vorhandener ## [Unreleased]-Abschnitt wird dabei nie angefasst. Er bleibt liegen, wo er war — also unterhalb der frisch eingefügten Version. Beim nächsten Release wiederholt sich das.

Zwei Folgen:

  1. Die ausführlichen Beschreibungen erscheinen in keinem Release. Ein Release trägt nur die eine Zeile aus der letzten Commit-Message. Beispiel [1.118.7]: dort steht „escape control bytes in email test fixture, reject dotted local part" — die eigentliche Änderung des Releases (ACME-Kontaktadresse konfigurierbar, dazu zwei Sicherheitsbefunde) steht in einem verwaisten Block weiter unten.
  2. 24 verwaiste [Unreleased]-Überschriften haben sich angesammelt, jede mit 2–16 Zeilen Inhalt.

Änderung

Steht direkt unter # Changelog ein [Unreleased]-Abschnitt mit Inhalt, wird seine Überschrift zur Version — der Inhalt reist also mit. Der aus der Commit-Message erzeugte Eintrag entfällt dann: hat jemand die Änderung beschrieben, ist die erste Zeile des letzten Commits die schlechtere Zusammenfassung.

Ist kein Abschnitt da oder ist er leer, bleibt alles wie bisher. Der Rückfall ist wichtig — sonst entstünde ein Versionsblock ganz ohne Inhalt.

Testbarkeit war das eigentliche Problem

Die Logik lag als awk-Einzeiler im YAML und war damit von keinem Test erreichbar — deshalb konnte der Fehler 24 Releases überstehen. Sie liegt jetzt in scripts/changelog-release.js, der Workflow ruft nur noch auf.

tests/changelog_release.test.js, 8 Fälle. Der wichtigste ist nicht der glückliche Pfad, sondern: nur der oberste Block wird befördert — die 24 Altlasten weiter unten dürfen nicht versehentlich zur Version werden. Dazu die Rückfall-Fälle (kein Block, leerer Block) und die Zuordnung Commit-Präfix → Rubrik.

Ende-zu-Ende gegen eine Kopie der echten Datei geprüft, beide Pfade:

$ node scripts/changelog-release.js 1.119.0 2026-07-26 "fix(security): probe"
inserted a generated block for [1.119.0]        # ohne Abschnitt
promoted the hand-written [Unreleased] block to [1.119.0]   # mit Abschnitt

actions/setup-node läuft im Job vor diesem Schritt (Zeile 68 vs. 114), node ist also verfügbar. YAML gegen js-yaml validiert.

Nicht enthalten: die 24 Altlasten

Bewusst unangetastet. Zwischen dem Schreiben eines Blocks und dem nächsten Release lagen teils mehrere Versionen; welche Version welchen Block ausgeliefert hat, lässt sich nicht zuverlässig rekonstruieren. Eine geratene Zuordnung würde den Verlauf unwahr machen, und das wäre schlimmer als unordentlich. Der Fix sorgt dafür, dass keine neuen dazukommen.

Volle Suite: 2339 bestanden, 0 fehlgeschlagen.

Comment thread scripts/changelog-release.js Fixed
@CallMeTechie
CallMeTechie force-pushed the fix/changelog-release-consumes-unreleased branch from 6b065ee to a49948d Compare July 26, 2026 19:01
@CallMeTechie
CallMeTechie merged commit ac6f05b into master Jul 26, 2026
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants