Skip to content

release workflow should derive GitHub release notes from the final merged CHANGELOG.md entry #50

@ricogu-claw

Description

@ricogu-claw

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.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions