DELIVERY: record the changelog assembler gate - #21
Conversation
A search that edits a file took the first match, which after a release was the previous version's section. Seven entries went into published release notes and the script said it had worked. Caught by reading the diff, so the gate was missing. It exists now and was watched failing before it was trusted.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (1)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe change documents a changelog placement failure and defines rules for targeting the ChangesChangelog guidance
Priority: ⬇️ Low Estimated code review effort: 1 (Trivial) | ~2 minutes Merge Risk: ⚪ Minimal · up to This change adds delivery guidance to prevent changelog entries from being placed in released sections. It introduces no runtime or deployment behavior and is ready to merge. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
One section, for the gate that came out of releasing barakoCMS 4.0.1.
scripts/changelog-assemble.shfolds one file per change intoCHANGELOG.md's Unreleased section.It found its
### Fixedheading with an unscoped search, and a release empties Unreleased, headingsincluded, so after 4.0.0 the first match in the file belonged to 4.0.0. Running it filed all seven
of 4.0.1's entries, two of them security, into the notes of a release that was already published.
It printed
Assembled 5 into Fixedand exited zero.It answers this document's three prompts cleanly, which is why it seemed worth a section rather than
just a fix:
docstring says so and its error message says "in the unreleased section", so the belief came from
the code itself.
changelog-assemble.sh --checkin CI beside it, which validates fragments and never asks where they land.
The fix is in BaryoDev/barakoCMS#705: searches scoped to the Unreleased section, a missing heading
created in place, and
scripts/test-changelog-assemble.shasserting where an entry lands, run inCI. Watched failing before it was trusted, 0 of 6 against the old logic and 6 of 6 after.
Placed after "Read the exit code, not the output", since it is the same family: a command that
reports success without saying what it did.
Summary by CodeRabbit