Skip to content

Automate changelog updates from GitHub releases#28

Merged
marianogoldman merged 1 commit into
masterfrom
release-automation
Jun 13, 2026
Merged

Automate changelog updates from GitHub releases#28
marianogoldman merged 1 commit into
masterfrom
release-automation

Conversation

@marianogoldman

Copy link
Copy Markdown
Contributor

Follow-up to #27. Sets up the GitHub-native release flow: you create the release in the GitHub UI, and CI keeps CHANGELOG.md in sync. No commit-message convention required; your current PR-based workflow stays the same.

How releasing works after this

  1. Merge PRs into master, labeled so the notes group nicely (security, enhancement, bug, dependencies, documentation).
  2. Releases → Draft a new release → new vX.Y.Z tag → Generate release notesPublish.
  3. The update-changelog.yml workflow writes those notes into CHANGELOG.md under ## vX.Y.Z - <date> and commits back to master. Packagist picks up the tag automatically.

Files

  • .github/release.yml — groups GitHub's auto-generated notes by PR label (Security / Features / Bug Fixes / Maintenance & Dependencies / Documentation), with a * catch-all so unlabeled PRs still show. Excludes dependabot and ignore-for-release.
  • .github/workflows/update-changelog.yml — on release: released, runs stefanzweifel/changelog-updater-action@v1 then commits via stefanzweifel/git-auto-commit-action@v7 (permissions: contents: write).
  • CHANGELOG.md — headings normalized to ## vX.Y.Z - <date> (matches what the action emits), Unreleased kept as an anchor with its compare link. The previously hand-written Unreleased bullets are intentionally dropped: at the next release, GitHub's auto-generated notes will capture the already-merged PRs (Support Laravel 13, drop Laravel 12 and update dependencies #25, Add README usage guide and AGENTS.md #26, Harden scheduling against unbounded ranges and invalid input #27) since v4.1.2, so nothing is lost — and keeping them would duplicate against the generated section.
  • README.md — documents the release process.

Notes / decisions

  • The action uses latest-version both as the heading text and in the Unreleased compare URL, so it must equal the real tag (vX.Y.Z). That's why headings carry the v prefix.
  • Prereleases don't touch the changelog (types: [released], not published).

Try it

Verified YAML parses; the workflow only runs on a published release, so the first real run will be the next release you cut.

🤖 Generated with Claude Code

Set up the GitHub-native release flow: create a release in the GitHub UI
(with auto-generated, label-grouped notes) and let CI keep CHANGELOG.md in
sync.

- .github/release.yml groups auto-generated release notes by PR label
  (Security, Features, Bug Fixes, Maintenance & Dependencies, Documentation),
  with a catch-all so unlabeled PRs still appear.
- .github/workflows/update-changelog.yml, on release: released, writes the
  release notes into CHANGELOG.md (stefanzweifel/changelog-updater-action) and
  commits back to master (git-auto-commit-action).
- Normalize changelog headings to "## vX.Y.Z - date" so they match what the
  action emits, keep the Unreleased anchor + its compare link, and drop the
  manually-maintained per-version compare links.
- Document the release process in the README.

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
@marianogoldman marianogoldman marked this pull request as ready for review June 13, 2026 12:54
@marianogoldman marianogoldman merged commit a27791e into master Jun 13, 2026
2 checks passed
@marianogoldman marianogoldman deleted the release-automation branch June 13, 2026 12:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant