The Changesets workflow is a useful way to manage a project's CHANGELOG file.
Unfortunately, it does not follow the Keep a Changelog standard
This action was written to grab the release notes for the most recent version in the CHANGELOG.md file for the project.
If the need arises, the functionality may be extended.
Path to the Changesets formatted CHANGELOG.md
| Option | Details |
|---|---|
| default | CHANGELOG.md |
| required | true |
The version to release
| Option | Details |
|---|---|
| default | latest |
| required | true |
The change entry for the version from the changelog.
- name: Last Change Entry
run: |
echo ${{ steps.get-changelog-info.outputs.last-change-entry }}The version number corresponding to the entry from the changelog, without
the v prefix.
This can be passed to a release action workflow (see below).
- name: Last Change Version
run: |
echo ${{ steps.get-changelog-info.outputs.last-change-version }}The version number corresponding to the entry from the changelog, including
the v prefix.
This can be passed to a release action workflow (see below).
- name: Last Change Version With V
run: |
echo ${{ steps.get-changelog-info.outputs.last-change-version-v }}In your workflow add the following you can usually use it out of the box with
no parameters. It will derive the information from CHANGELOG.md for the most
recent (top of file) version.
- name: Get Changelog Entry
id: get-changelog-entry
uses: chizovation/[email protected]If your change file is in a non-standard location:
- name: Get Changelog Entry
id: get-changelog-entry
uses: chizovation/[email protected]
with:
changelog: path-to/my-change-file.mdCreate .github/workflows/github-release.yml in your project with the
following content:
---
name: Github Release
# yamllint disable-line rule:truthy
on:
push:
tags:
- v*
permissions:
contents: write
jobs:
create-release:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v2
- name: Get Change Info
id: get-changelog-info
uses: chizovation/[email protected]
- name: Create Github Release
uses: softprops/action-gh-release@v1
# only run if we have a changelog entry
if: steps.get-changelog-info.outputs.last-change-entry != ''
with:
body: ${{ steps.get-changelog-info.outputs.last-change-entry }}
tag_name: ${{ steps.get-changelog-info.outputs.last-change-version }}
name: ${{ steps.get-changelog-info.outputs.last-change-version }}
draft: false
prerelease: falseNOTE: using a v* tag as a release trigger requires some additions to your
changeset-release.yml (or equivalent) workflow, to push the tags back to the
repo.
Add the following after your changesets/action step:
- name: Push Tags
# https://github.com/changesets/action#custom-publishing
if: steps.changesets.outputs.hasChangesets == 'false'
shell: bash
run: |
git tag ${{ steps.get-changelog-info.outputs.last-change-version }}
# this could fail in a merge without changesets
# (e.g. update README.md, merge)
# but that's a bit naughty anyway, so we'll let it fail
git push --tagFor an example of a Changeset Release workflow file you can view .github/workflows/changeset-release.yml
From Triggering a workflow from a workflow:
When you use the repository's GITHUB_TOKEN to perform tasks, events triggered by the GITHUB_TOKEN will not create a new workflow run.
If you do want to trigger a workflow from within a workflow run, you can use a GitHub App installation access token or a personal access token instead of GITHUB_TOKEN to trigger events that require a token.
This project uses a personal access token called CHANGESETS_TOKEN.
If you already have a
personal access token
configured in your repo, or organization, you should replace any references to
match the name of your secret.
For your reference, CHANGESETS_TOKEN has been created as a Classic Token
with the following permissions:
repo