Summary
PR #40 (#40) fixes the critical sequencing bug by waiting for the changelog PR to merge before tagging. That is a real improvement.
However, the workflow still creates the GitHub release body from the earlier release-changelog-builder-action output instead of the final merged CHANGELOG.md content.
Why this still matters after PR #40
Even after the changelog PR is merged, the release is currently created with:
body: ${{ steps.changelog.outputs.changelog }}
That means the GitHub release notes are still based on the pre-merge generated text, not on the final committed changelog entry that actually landed on main.
So if the generated changelog content is edited, reformatted, or otherwise adjusted before merge, the repository changelog and the GitHub release notes can still drift.
Concrete example
This surfaced around the v1.0.1 changelog flow:
Expected behavior
The workflow should use one final source of truth for both:
- the committed changelog entry in
CHANGELOG.md
- the GitHub release notes
Suggested approaches
- After checking out updated
main, extract the newly-added CHANGELOG.md section for the target version and use that as the release body
- Or generate the changelog once, commit exactly that content, then read back the committed result before creating the release
Goal
After this is fixed, the release workflow should guarantee that the published GitHub release notes match the final merged changelog entry exactly.
Summary
PR #40 (#40) fixes the critical sequencing bug by waiting for the changelog PR to merge before tagging. That is a real improvement.
However, the workflow still creates the GitHub release body from the earlier
release-changelog-builder-actionoutput instead of the final mergedCHANGELOG.mdcontent.Why this still matters after PR #40
Even after the changelog PR is merged, the release is currently created with:
That means the GitHub release notes are still based on the pre-merge generated text, not on the final committed changelog entry that actually landed on
main.So if the generated changelog content is edited, reformatted, or otherwise adjusted before merge, the repository changelog and the GitHub release notes can still drift.
Concrete example
This surfaced around the v1.0.1 changelog flow:
CHANGELOG.mdExpected behavior
The workflow should use one final source of truth for both:
CHANGELOG.mdSuggested approaches
main, extract the newly-addedCHANGELOG.mdsection for the target version and use that as the release bodyGoal
After this is fixed, the release workflow should guarantee that the published GitHub release notes match the final merged changelog entry exactly.