A batteries-included and opinionated drop-in solution to generating and managing github release notes.
Two main workflows
Input | Required | Type | Default | Description |
---|---|---|---|---|
branch-with-candidate-code |
No | string | Optionally provide a specific branch that contains the candidate code, otherwise the default branch of the repository will be selected. |
Output | Description |
---|---|
CANDIDATE_BRANCH |
The branch that was used to generate release notes from |
CANDIDATE_COMMIT |
The latest commit hash from the candidate branch |
URL |
Link to the release candidate |
Input | Required | Type | Default | Description |
---|---|---|---|---|
tag |
Yes | string | Tag to associate the release to. Can be new or existing. | |
auto-clear-release-candidate-notes |
No | boolean | true |
Whether the notes of the release candidate should be cleared |
Output | Description |
---|---|
URL |
Link to the release |
Create a .github/release.yml
This will define the categorial structure of the release notes. When a pull request label matches an entry in the release.yml
, it will be placed under the respective section. It matched against the first label to have an entry in the categories
section.
Sample release.yml
changelog:
categories:
- title: 🎉 New Features
labels:
- new feature
- title: ✨ Enhancements
labels:
- enhancement
- title: 🛠 Breaking Changes
labels:
- breaking change
- title: 🐛 Bug fixes
labels:
- bug
- title: ⚡️ Optimisations
labels:
- optimisation
- title: 🔭 Observability
labels:
- observability
- title: 🔒️ Security
labels:
- security
- title: 📝 Documentation
labels:
- documentation
- title: 📦️ Dependencies
labels:
- dependencies
- title: Other Changes
labels:
- '*'
A long-lived mutable release-candidate
tag can optionally be managed through the action reusable-update-release-candidate-notes.yml
.
This will persist a single release instance for candidate changes that moves when changes are being made to your repository.
jobs:
update-candidate:
name: Update Release Candidate Notes
permissions:
id-token: write
contents: write
uses: danielebra/simple-release-notes/.github/workflows/reusable-update-release-candidate-notes.yml
with:
branch-with-candidate-code: main
This image demonstrates a release candidate managed by the above workflow.
The latest release is managed by detecting the current latest release before creating a new one. Given this spread, release notes will automatically be generated, alongside a change diff. A release will be published that is now marked as latest
. The release title is named after the tag of the release.
jobs:
create-release
name: Create Release Notes
permissions:
id-token: write
contents: write
uses: danielebra/simple-release-notes/.github/workflows/reusable-create-release-notes.yml
with:
tag: v1.0.0
The default behaviour of the reusable-create-release-notes
workflow will automatically clear the release notes from the candidate release. To disable candidate notes, you can opt-out of this via
with:
auto-clear-release-candidate-notes: false