Conversation
The previous design had release.yml auto-rename [Unreleased] → [X.Y.Z]
and push the rename commit back to main as github-actions[bot]. That
collided with branch protection on main:
remote: error: GH013: Repository rule violations found for refs/heads/main.
- Changes must be made through a pull request.
- 3 of 3 required status checks are expected.
- Commits must have verified signatures.
Rather than weakening branch protection or adding a bypass token, flip
the flow: the release workflow now ONLY reads from CHANGELOG.md. It
extracts `## [vX.Y.Z]` (or `## [X.Y.Z]`) and fails loudly if the section
is absent, instructing the maintainer to open a PR first.
Release procedure:
1. Open PR: add `## [X.Y.Z] — YYYY-MM-DD` with curated bullets to
CHANGELOG.md (or rename [Unreleased] to [X.Y.Z]).
2. Merge it.
3. `gh workflow run release.yml --ref main -f bump=patch`.
Benefits:
- CHANGELOG.md is only ever modified via normal PR review.
- Branch protection stays intact, no bot bypass needed.
- Release notes are reviewable before the release fires.
- Workflow has no `contents: write` side-effects to the source tree.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
…sset
Previous design required maintaining a ## [vX.Y.Z] section in CHANGELOG.md
via a pre-release PR. User feedback: "no overhead" — don't make me
maintain CHANGELOG.md in-repo.
New design:
1. release.yml accepts a `notes` input (Markdown). The maintainer
provides the release notes at release time:
gh workflow run release.yml --ref main \\
-f bump=patch \\
-f notes=$'### Changed\\n\\n- ...'
2. The workflow uses `notes` verbatim as the GitHub release body,
AND writes the same content to dist/CHANGELOG.md, uploaded as a
release asset.
3. In-repo CHANGELOG.md is now a thin static pointer to the Releases
page. Zero per-release maintenance. No auto-commits. No pre-release
PR.
This matches the user's "create a changelog.md file in release itself
with the content same as release note. no overhead" directive.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Revised approach
After the initial "extract from CHANGELOG.md" design, the user requested zero in-repo overhead:
So this PR flips the flow again — release notes come from a `notes` workflow input, not from a CHANGELOG.md section.
New release procedure
```sh
gh workflow run release.yml --ref main \
-f bump=patch \
-f notes=$'### Changed\n\n- Describe changes here...\n\n### Upgrade impact\n\nDrop-in replacement.'
```
That's the entire release flow. One CLI command.
What happens
What's removed
What stays
Files
Net: -117 / +41 lines.
Test plan (for v0.0.4)
Merge this PR
Run:
Confirm release v0.0.4 on GitHub:
🤖 Generated with Claude Code