A GitHub Action that generates a markdown changelog between two git references, ideal for populating release notes.
Changelog Generator is a GitHub Action that automatically creates markdown-formatted changelogs by comparing two git references, such as commits or release tags. It solves the problem of manually compiling release notes for GitHub Releases, providing a simple, automated way to document changes between versions. The action outputs a clean changelog that can be directly used in release bodies or other documentation.
Developers and DevOps engineers using GitHub Actions who need to automate the generation of release notes or changelogs for their projects. It is particularly useful for maintainers of open-source or private repositories who regularly create GitHub Releases.
Developers choose Changelog Generator for its simplicity and reliability—it avoids the complexity of milestone or label-based systems, focusing solely on git reference comparison. Its minimalist design, security features like build provenance, and ease of integration make it a trusted tool for automated changelog generation in CI/CD pipelines.
GitHub Action to generate changelogs, release notes, whatever
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Directly compares two git references like commits or tags, avoiding the complexity of milestone-based systems mentioned in the README.
Generates clean markdown formatted changelogs that are immediately usable in GitHub Releases, as shown in the example image and workflow.
Includes build provenance attestations via Sigstore and recommends pinning to commit SHAs for supply chain security, detailed in the README's security section.
Allows reversing the commit order with the `reverse` input, providing flexibility in how changelogs are presented.
The README explicitly states no plans to add more flags for output modifications, forcing users to rely on external command-line tools for filtering or formatting.
The default base-ref requires a GitHub Release, not just a git tag, which can cause errors if releases aren't set up, as noted in the troubleshooting section.
For branches with forward slashes, users must manually adjust by adding 'origin/' and setting `fetch: false`, adding setup complexity beyond basic usage.