A GitHub Action to automatically bump and tag master, on merge, with the latest SemVer formatted version. Works on any platform.
name: Bump version
on:
push:
branches:
- master
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Bump version and push tag
id: tag_version
uses: mathieudutour/[email protected]
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
- name: Create a GitHub release
uses: ncipollo/release-action@v1
with:
tag: ${{ steps.tag_version.outputs.new_tag }}
name: Release ${{ steps.tag_version.outputs.new_tag }}
body: ${{ steps.tag_version.outputs.changelog }}
- github_token (required) - Required for permission to tag the repo. Usually
${{ secrets.GITHUB_TOKEN }}
. - commit_sha (optional) - The commit SHA value to add the tag. If specified, it uses this value instead GITHUB_SHA. It could be useful when a previous step merged a branch into github.ref.
- fetch_all_tags (optional) - By default, this action fetch the last 100 tags from Github. Sometimes, this is not enough and using this action will fetch all tags recursively (default:
false
).
- release_branches (optional) - Comma separated list of branches (JavaScript regular expression accepted) that will generate the release tags. Other branches and pull-requests generate versions postfixed with the commit hash and do not generate any repository tag. Examples:
master
or.*
orrelease.*,hotfix.*,master
... (default:master,main
). - pre_release_branches (optional) - Comma separated list of branches (JavaScript regular expression accepted) that will generate the pre-release tags.
- scopes (optional) - Comma separated list of scopes (JavaScript regular expression accepted) to consider when tagging, and to include in the changelog. If this option is specified, then commits with scopes not matching this list will not be analyzed nor included in the changelog.
- default_bump (optional) - Which type of bump to use when none is explicitly provided when commiting to a release branch (default:
patch
). You can also setfalse
to avoid generating a new tag when none is explicitly provided. Can bepatch, minor or major
. - default_prerelease_bump (optional) - Which type of bump to use when none is explicitly provided when commiting to a prerelease branch (default:
prerelease
). You can also setfalse
to avoid generating a new tag when none is explicitly provided. Can beprerelease, prepatch, preminor or premajor
. - custom_tag (optional) - Custom tag name. If specified, it overrides bump settings.
- create_annotated_tag (optional) - Boolean to create an annotated rather than a lightweight one (default:
false
). - tag_prefix (optional) - A prefix to the tag name (default:
v
). - append_to_pre_release_tag (optional) - A suffix to the pre-release tag name (default:
<branch>
).
-
custom_release_rules (optional) - Comma separated list of release rules.
Format:
<keyword>:<release_type>:<changelog_section>
where<changelog_section>
is optional and will default to Angular's conventions.Examples:
hotfix:patch,pre-feat:preminor
,bug:patch:Bug Fixes,chore:patch:Chores
- dry_run (optional) - Do not perform tagging, just calculate next version and changelog, then exit
- new_tag - The value of the newly calculated tag. Note that if there hasn't been any new commit, this will be
undefined
. - new_version - The value of the newly created tag without the prefix. Note that if there hasn't been any new commit, this will be
undefined
. - previous_tag - The value of the previous tag (or
v0.0.0
if none). Note that ifcustom_tag
is set, this will beundefined
. - previous_version - The value of the previous tag (or
0.0.0
if none) without the prefix. Note that ifcustom_tag
is set, this will beundefined
. - release_type - The computed release type (
major
,minor
,patch
orcustom
- can be prefixed withpre
). - changelog - The conventional changelog since the previous tag.
Note: This action creates a lightweight tag by default.
The action will parse the new commits since the last tag using the semantic-release conventions.
semantic-release uses the commit messages to determine the type of changes in the codebase. Following formalized conventions for commit messages, semantic-release automatically determines the next semantic version number.
By default semantic-release uses Angular Commit Message Conventions.
Here is an example of the release type that will be done based on a commit messages:
Commit message | Release type |
|
Patch Release |
|
Minor Release |
|
Major Release |
If no commit message contains any information, then default_bump will be used.
anothrNick/github-tag-action - a similar action using a Dockerfile (hence not working on macOS)