GitHub Action
GitHub Actions Create Tag
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@master
- name: Bump version and push tag
uses: laputansoft/github-tag-action@v1.2
with:
github_token: ${{ env.github-token }}
tag: ${{ steps.package-version.outputs.version }}
- github_token (required) - Required for permission to tag the repo. Usually
${{ secrets.GITHUB_TOKEN }}
. - default_bump (optional) - Which type of bump to use when none is explicitly provided (default:
patch
). You can also setfalse
to avoid generating a new tag when none is explicitly provided. - tag (optional) - Tag name (default:
0.0.1
). - release_branches (optional) - Comma separated list of branches (bash reg exp accepted) that will generate the release tags. Other branches and pull-requests generate versions postfixed with the commit hash and do not generate any tag. Examples:
master
or.*
orrelease.*,hotfix.*,master
... (default:master
). - create_annotated_tag (optional) - Boolean to create an annotated rather than a lightweight one (default:
false
). - dry_run (optional) - Do not perform taging, just calculate next version and changelog, then exit
- new_tag - The value of the newly created tag. Note that if there hasn't been any new commit, this will be
undefined
. - latest_hash - Latest commit hash.
- previous_tag - The value of the previous tag (or
0.0.0
if none). - 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 |
---|---|
fix(pencil): stop graphite breaking when too much pressure applied |
Patch Release |
feat(pencil): add 'graphiteWidth' option |
Minor Release |
perf(pencil): remove graphiteWidth option BREAKING CHANGE: The graphiteWidth option has been removed. The default graphite width of 10mm is always used for performance reasons. |
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) mathieudutour/github-tag-action - fork from mathieudutour