Stop using files for versioning. Use git tags instead!
Github Action to create a Github Release on pushes to master.
- Flexible version bumping scheme with a project default or overrides using Pull Request Labels
- Creates Release Notes automatically (with a list of commits since the last release)
CI & CD systems are simpler when they work with immutable monotonic identifers from the get-go. Trigger your release activites by subscribing to new tags pushed from this Action.
For automation, Github Releases (and by extension git tags) are better than versioned commit files for these reasons:
- Agnostic of language & ecosystem (i.e. does not rely on presence of package.json)
- Tagging does not require write permissions to bump version
- Tagging does not trigger infinite-loop webhooks from pushing version bump commits
on:
push:
branches:
- master
jobs:
release-on-push:
runs-on: ubuntu-latest
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
steps:
- uses: rymndhng/release-on-push-action@master
with:
bump_version_scheme: minor
Allowed values of bump_version_scheme
:
- minor
- major
- patch
- norelease: Performs no release by default. Creation of release delegated to labels on Pull Requests.
For stability, we recommend pinning the version of the action. See Releases.
See action.yml for the full list of options.
There are several approaches:
- Put
[norelease]
in the commit title. - If the commit has an attached PR, add the label
norelease
to the PR. - Set the action's
bump_version_scheme
tonorelease
to disable this behavior by default
Iif the PR has the label release:major
, release:minor
, or release:patch
, this will override bump_version_scheme
.
This repository's pull requests are an example of this in action. For example, #19.
Only one of these labels should be present on a PR. If there are multiple, the behavior is undefined.
Github Actions will inject a token for this plugin to interact with the API.
You need to enable read and write permission
to this token under settings > actions > general > workflow permissions
(disabled by default).
Currently, no.
In order to reliably generate monotonic versions, we use Github Releases to track what the last release version is. See Release#get-the-latest-release.
On a successful release, this action creates an output parameters tag_name
and version
.
Example of how to consume this:
on:
push:
branches:
- master
jobs:
release-on-push:
runs-on: ubuntu-latest
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
steps:
- id: release
uses: rymndhng/release-on-push-action@master
with:
bump_version_scheme: minor
tag_prefix: v
- name: Check Output Parameters
run: |
echo "Got tag name ${{ steps.release.outputs.tag_name }}"
echo "Got release version ${{ steps.release.outputs.version }}"
Yes you can, with release_body
. The contents of this be appended to the release description.
Example:
on:
push:
branches:
- master
jobs:
release-on-push:
runs-on: ubuntu-latest
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
steps:
- uses: rymndhng/release-on-push-action@master
with:
bump_version_scheme: minor
release_body: "When set, adds extra text to body!"
Yes you can, by setting use-github-release-notes
to true
. For more information, see Automatic Release Notes.
Note, if enabling this feature:
- If you have set
release_body
, therelease_body
will be prepended to the Generated Release Notes - Enabling this will disable the commit summary generated by this project
Example:
on:
push:
branches:
- master
jobs:
release-on-push:
runs-on: ubuntu-latest
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
steps:
- uses: rymndhng/release-on-push-action@master
with:
bump_version_scheme: minor
use_github_release_notes: true
Yes, you can customize this by changing the tag_prefix
. Here's an example of
removing the prefix by using an empty string.
on:
push:
branches:
- master
jobs:
release-on-push:
runs-on: ubuntu-latest
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
steps:
- uses: rymndhng/release-on-push-action@master
with:
tag_prefix: ""
Yes, you can customize this by changing the release_name
. The release_name
supports these template variables:
<RELEASE_VERSION>
contains the version number, i.e.1.2.3
<RELEASE_TAG>
contains the git tag name, i.e.v1.2.3
See example below for how to create a release with the name Release 1.2.3
on:
push:
branches:
- master
jobs:
release-on-push:
runs-on: ubuntu-latest
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
steps:
- uses: rymndhng/release-on-push-action@master
with:
tag_prefix: "v"
release_name: "Release <RELEASE_VERSION>"
Use the option max_commits
. The default value is 50.
on:
push:
branches:
- master
jobs:
release-on-push:
runs-on: ubuntu-latest
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
steps:
- uses: rymndhng/release-on-push-action@master
with:
max_commits: 100
Uses babashka
To run tests:
export GITHUB_TOKEN=<YOUR_TOKEN>
export GITHUB_REPOSITORY=rymndhng/release-on-push-action
export GITHUB_SHA=167c690247d0933acde636d72352bcd67e33724b
export GITHUB_API_URL=https://api.github.com
export INPUT_BUMP_VERSION_SCHEME=minor
export INPUT_MAX_COMMITS=5
export INPUT_TAG_PREFIX=v
export INPUT_RELEASE_NAME="<RELEASE_TAG>"
export INPUT_DRY_RUN=1
- Run Tests
make test
make dryrun