Uh oh!
There was an error while loading. Please reload this page.
ci: Add action to validate changelog diffs after merging - #7525
Conversation
There was a problem hiding this comment.
This is a plain JS file so we can just call node check-changelog-diff.cjs without installing dependencies etc.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Gudahtt
left a comment
There was a problem hiding this comment.
LGTM! I had a couple of minor questions but no blockers

Explanation
This fixes an issue in changelogs where changelog entries may be incorrectly moved after merging into the main branch. Given the following (partial) changelog for example:
After a release, this changelog may look like this:
## [Unreleased] + ## [1.0.0] ### Changed - Changelog entry A ([#1234](...)) - Changelog entry B ([#5678](...)) - Changelog entry C ([#1337](...))But if another PR based on the original changelog also adds an entry to the unreleased section like this:
## [Unreleased] ### Changed - Changelog entry A ([#1234](...)) - Changelog entry B ([#5678](...)) - Changelog entry C ([#1337](...)) + - Changelog entry D ([#0000](...))The final changelog will look like this, since Git can merge the entry based on the other entries around it:
Here it appears that the release included "entry D", but in reality that was meant to be under the unreleased section.
To address this issue, I've added a simple workflow that checks for changelog diffs. It uses a minimal algorithm to parse the markdown files, find entries that are included in unreleased originally, and checks if they still are after merging. If not, the workflow will fail and show an error such as this:
Long term we should solve this problem by using changesets instead, in which case the unreleased changes will never be merged or conflict with each other, but until we figure out how to implement those in our release workflows, we can use this workflow.
References
Checklist
Note
Low Risk
Low risk CI-only change that adds a new workflow gate; main failure mode is false positives/negatives that could block merges.
Overview
Adds a new composite GitHub Action (
check-merge-queue-changelogs) and Node script to detect when changelog lines introduced in a PR get moved out of the## [Unreleased]section after merge (a common merge-queue conflict artifact).Updates
lint-build-test.ymlto run a newvalidate-changelog-diffsjob onpull_requestandmerge_groupevents, failing the workflow when modifiedCHANGELOG.mdfiles lose newly-added Unreleased entries in the merged result.Written by Cursor Bugbot for commit ef5a189. This will update automatically on new commits. Configure here.