Skip to content
You're viewing an older version of this GitHub Action. Do you want to see the latest version instead?
git-merge

GitHub Action

GitHub Tag

v5.4

GitHub Tag

git-merge

GitHub Tag

Bump and push git tag on merge

Installation

Copy and paste the following snippet into your .yml file.

              

- name: GitHub Tag

uses: mathieudutour/[email protected]

Learn more about this action in mathieudutour/github-tag-action

Choose a version

GitHub Tag Action

A GitHub Action to automatically bump and tag master, on merge, with the latest SemVer formatted version. Works on any platform.

Usage

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: actions/create-release@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          tag_name: ${{ steps.tag_version.outputs.new_tag }}
          release_name: Release ${{ steps.tag_version.outputs.new_tag }}
          body: ${{ steps.tag_version.outputs.changelog }}

📥 Inputs

  • github_token (required) - Required for permission to tag the repo. Usually ${{ secrets.GITHUB_TOKEN }}.

Filter branches

  • 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 .* or release.*,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.

Customize the tag

  • default_bump (optional) - Which type of bump to use when none is explicitly provided (default: patch). You can also set false to avoid generating a new tag when none is explicitly provided.
  • 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>).

Customize the conventional commit messages & titles of changelog sections

  • 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:

    1. hotfix:patch,pre-feat:preminor,
    2. bug:patch:Bug Fixes,chore:patch:Chores

Debugging

  • dry_run (optional) - Do not perform tagging, just calculate next version and changelog, then exit

📤 Outputs

  • 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 if custom_tag is set, this will be undefined.
  • previous_version - The value of the previous tag (or 0.0.0 if none) without the prefix. Note that if custom_tag is set, this will be undefined.
  • changelog - The conventional changelog since the previous tag.

Note: This action creates a lightweight tag by default.

Bumping

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.

Credits

anothrNick/github-tag-action - a similar action using a Dockerfile (hence not working on macOS)