Incorporate change-notes into CHANGELOG.md at release - #4201
mbg merged 6 commits into
Conversation
Sorry, something went wrong.
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
Changenote deletions are not committed and can occur before the changelog is successfully written.
Review effort: Balanced
Findings: 1
Automates incorporating unreleased changenotes into the changelog during release preparation.
Changes:
- Extracts reusable changenote transfer logic.
- Integrates changenote assembly into release branch preparation.
- Updates ESM entry-point detection.
| File | Description |
|---|---|
| pr-checks/changenotes.mts | Adds reusable changenote assembly and cleanup. |
| pr-checks/update-release-branch.mts | Runs assembly when updating the release changelog. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Sorry, something went wrong.
There was a problem hiding this comment.
Copilot review overview
🟢 Approval recommended
The release workflow integration is focused and correctly stages both the populated changelog and removed changenotes.
Review effort: Balanced
Findings: None
Sorry, something went wrong.
mbg
left a comment
There was a problem hiding this comment.
This basically LGTM. I'd say that we should hold off from merging this until the current CLI release has wrapped up though (including the CodeQL Action release that's part of that process) so that, if there is a problem with this, we don't accidentally throw a spanner into that process -- especially since we don't currently have any change notes.
Two things I'd like to see on top of what's here:
- A workflow (or check in an existing one) that runs for ordinary PRs (not release PRs) and which complains (but doesn't necessarily fail) if the PR changes CHANGELOG.md directly. That can be an independent PR from this one.
- It would be good to improve our test coverage here for this. I know that changenotes.ts has its own ones that test the functions there, but it would be good to have something more end-to-end. Let's chat about how to best approach that.
Sorry, something went wrong.
|
Thanks for performing a test run! There are a couple of minor extra things to check there, which I have let you know. Once we have confirmed those, we can merge this. |
Sorry, something went wrong.
This PR automates the effective execution of pr-checks/changenotes.mts assemble into the update-release-branch process by refactoring the code to be importable, and then importing it into pr-checks/update-release-branch.ts.
Testing
In my test fork, I dispatched update-release-branch.yml to confirm expected behaviour.
Test 1
Test 2
Risk assessment
For internal use only. Please select the risk level of this change:
Which use cases does this change impact?
Workflow types:
Products:
Environments:
How did/will you validate this change?
If something goes wrong after this change is released, what are the mitigation and rollback strategies?
How will you know if something goes wrong after this change is released?
Are there any special considerations for merging or releasing this change?
Merge / deployment checklist