GitHub Action for Automated Changelogs: Generate Release Notes from Conventional Commits in CI/CD
Stop writing changelogs by hand. Our new GitHub Action parses conventional commits and generates formatted changelogs automatically — as PR comments, job summaries, release notes, or files. One line of YAML. Zero config.
The problem with manual changelogs
Every developer knows the feeling. You are tagging a release, and someone asks: "What changed since the last version?" You open the git log, scroll through dozens of commits, try to remember which ones matter, and cobble together a summary. It takes 20 minutes. Nobody reads it.
Or worse — you skip the changelog entirely. Your users see a version bump with no explanation. Support tickets roll in. Trust erodes one silent deploy at a time.
If you already write conventional commits, the information is already there. It just needs to be extracted and formatted. That is exactly what our new GitHub Action does.
Introducing changelog-action
The Changelog Generator Action is a free, open-source GitHub Action that generates changelogs from your conventional commits. It wraps changelogdev-cli and runs inside any GitHub Actions workflow.
The simplest possible setup:
That single line generates a changelog from all your commits and adds it to the GitHub Actions job summary. No API keys. No configuration files. No dependencies to install.
Three workflows, three use cases
Most teams need changelogs in one of three places: on pull requests, in release notes, or committed to a file. The action handles all three.
1. Add a changelog to every PR
This is the most common use case. When a contributor opens a pull request, the action reads the commits in that branch and posts a formatted changelog as a PR comment. Reviewers see exactly what changed without digging through individual commits.
The fetch-depth: 0 flag is important — it tells the checkout action to pull full git history so the changelog generator can see all commits, not just the latest one.
2. Generate release notes automatically
When you push a version tag, this workflow generates a changelog filtered to features and bug fixes from the last month, then passes it to the GitHub Release action. Your releases get professional, categorized notes without any manual writing.
The from input accepts dates (like 2026-01-01 or last month) and git refs. The type filter lets you include only the commit categories your users care about.
3. Write to CHANGELOG.md
Some projects keep a CHANGELOG.md in the repository root. The action can write directly to a file, which you can then commit in a subsequent step or review in a PR.
All inputs and outputs
The action exposes six inputs, all optional:
| Input | Default | Description |
|---|---|---|
| from | (all commits) | Start date or git ref |
| to | (latest) | End date or git ref |
| type | (all types) | Filter commit types (comma-separated) |
| output-file | (none) | Write changelog to file |
| add-to-summary | true | Add to job summary |
| add-to-pr | false | Post as PR comment |
And two outputs you can reference in downstream steps:
| Output | Description |
|---|---|
| changelog | Generated changelog in markdown |
| commit-count | Number of commits included |
How conventional commits become changelogs
The action parses each commit message according to the Conventional Commits specification and groups them by type. A commit like feat: add dark mode toggle lands under "New Features." A commit like fix: resolve login timeout on slow connections goes under "Bug Fixes."
The supported types include feat, fix, perf, refactor, docs, test, build, ci, and chore. Non-conventional commits are grouped under "Other Changes" so nothing gets lost.
Why not just use GitHub's built-in release notes?
GitHub's auto-generated release notes list every PR title between two tags. That is useful, but it has limits:
- +No commit-level detail — it works at the PR level, so squashed PRs with multiple features show as a single line.
- +No type filtering — you cannot exclude chores, CI changes, or docs commits from user-facing notes.
- +No PR comments — the built-in feature only works at release time, not during code review.
- +No file output — you cannot write the result to CHANGELOG.md automatically.
- +No date filtering — you cannot generate a changelog for "the last 30 days" across multiple releases.
The Changelog Generator Action fills these gaps. Use it alongside GitHub's release notes or as a replacement — your call.
Part of the Changelog.dev ecosystem
This action is one piece of a broader toolkit for teams that take changelogs seriously:
- +Changelog.dev — Hosted changelog pages for SaaS products. Public pages, subscriber emails, custom domains.
- +changelogdev-cli — The CLI that powers this action. Run it locally or in any CI system.
- +changelogdev-widget — An embeddable Web Component that adds a "What's New" bell to your app. Under 8KB.
Each tool works independently. Use the GitHub Action alone, combine it with the widget, or go all-in with a hosted Changelog.dev page. They compose, they do not lock you in.
Get started in 60 seconds
Create a file at .github/workflows/changelog.yml in your repository with the PR comment workflow above. Push it. Open a pull request. The changelog appears as a comment within seconds.
If your team does not use conventional commits yet, now is a good time to start. The specification is simple — prefix your commit message with a type like feat: or fix:. That is the only requirement. The action handles everything else.