Release-Workflow übernimmt den handgeschriebenen Unreleased-Abschnitt - #234
Merged
Merged
Conversation
CallMeTechie
force-pushed
the
fix/changelog-release-consumes-unreleased
branch
from
July 26, 2026 19:01
6b065ee to
a49948d
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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:
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.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.[Unreleased]-Überschriften haben sich angesammelt, jede mit 2–16 Zeilen Inhalt.Änderung
Steht direkt unter
# Changelogein[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:
actions/setup-nodeläuft im Job vor diesem Schritt (Zeile 68 vs. 114),nodeist also verfügbar. YAML gegenjs-yamlvalidiert.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.