Giter Club home page Giter Club logo

github-tag-action's Introduction

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@v4
      - 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 }}

๐Ÿ“ฅ Inputs

  • 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

  • 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).

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 when commiting to a release branch (default: patch). You can also set false to avoid generating a new tag when none is explicitly provided. Can be patch, 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 set false to avoid generating a new tag when none is explicitly provided. Can be prerelease, 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>).

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.
  • release_type - The computed release type (major, minor, patch or custom - can be prefixed with pre).
  • 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)

github-tag-action's People

Contributors

alexesprit avatar andres99x avatar bissim avatar chrisjohnson00 avatar davidolrik avatar dependabot[bot] avatar dragonraid avatar duality72 avatar hennejg avatar jdrphillips avatar jimrazmus avatar johntitor avatar jonerickson avatar koiralakiran1 avatar kzrnm avatar mathieudutour avatar miluoshi avatar naresh-gn avatar olilin avatar orenkl avatar qvistgaard avatar rovel avatar sauramirez avatar sebbacon avatar stschmaltz avatar teruyamato0731 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

github-tag-action's Issues

Add ref parameter

I currently try to create a pre-release when a user comments "pre-release" on a PR.
However, in that case GITHUB_REF refers to the default branch. Being able to define the ref the version is meant for would enable this use-case.

Tags are never created

My goal is to tag all commits that pass testing. I have a template that already includes the tests. So I added this action to add the tags.

The action runs, whoever it never adds a tag. I tried with lightweight and annotated tags and with the exact same example configuration with no luck. I ended up asking for help on Stackoverflow and they recommended I report it as a bug: https://stackoverflow.com/questions/65227046/github-tag-action-does-not-add-tag/65227304#65227304

Here is my previous build.yml that included github-tag-action:

# Automatically build the project and run any configured tests for every push
# and submitted pull request. This can help catch issues that only occur on
# certain platforms or Java versions, and provides a first line of defence
# against bad commits.

name: build
on:
  pull_request:
    branches: ['*']
  push:
    branches: ['master']

jobs:
  build:
    strategy:
      matrix:
        # Use these Java versions
        java: [
          1.8,  # Minimum supported by Minecraft
          11,   # Current Java LTS
          15    # Latest version
        ]
        # and run on both Linux and Windows
        os: [ubuntu-20.04, windows-latest]
    runs-on: ${{ matrix.os }}
    steps:
      - uses: actions/checkout@v2
      - name: bump version and push tag
        id: tag_version
        if: ${{ github.event_name == 'push' && runner.os == 'Linux' && matrix.java == '11' }}
        uses: mathieudutour/[email protected]
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          create_annotated_tag: true
      - name: validate gradle wrapper
        uses: gradle/wrapper-validation-action@v1
      - name: setup jdk ${{ matrix.java }}
        uses: actions/setup-java@v1
        with:
          java-version: ${{ matrix.java }}
      - name: make gradle wrapper executable
        if: ${{ runner.os != 'Windows' }}
        run: chmod +x ./gradlew
      - name: build
        run: ./gradlew build
      - name: capture build artifacts
        if: ${{ runner.os == 'Linux' && matrix.java == '11' }} # Only upload artifacts built from LTS java on one OS
        uses: actions/upload-artifact@v2
        with:
          name: Artifacts
          path: build/libs/

And here was the last run with that action:

Run mathieudutour/[email protected]
  with:
    github_token: ***
    create_annotated_tag: true
    default_bump: patch
    tag_prefix: v
    release_branches: master
    dry_run: false

Semver increment not work with PR

I guess that calculating the origin branch of the PR can be a solution

Run mathieudutour/github-tag-action@v5
  with:
    github_token: ***
    dry_run: true
    default_bump: patch
    tag_prefix: v
    release_branches: master
    create_annotated_tag: false
Previous tag was 1.0.0.
Analysis of 0 commits complete: no release
Error: 1.0.1-refs/pull/3/merge.0 is not a valid semver.

(Discussion) Use 'conventionalcommits' preset instead of 'angular' to support custom changelog sections

Hi Mathieu,

I'm working on a fix for #54. I've mentioned why this is closed but not fixed in this comment.

So, before creating a PR for this, I just wanted to get your feedback beforehand on the approach that I'm taking.

Here's what I'm doing to fix this:

const changelog = await generateNotes(
{},

  • Right now, custom_release_rules supports <keyword>:<release_type>. I'm thinking of adding another section to this that mentions the changelog section/title the commits in this group should persist in. i.e. <keyword>:<release_type>:<changelog_section>
    Any support for gitmoji in the changelog section/title will already be supported after #67 is fixed.

  • This last/new section will be optional whose default value will be what's used on conventional-changelog-angular. Any rules the user provides will override the rule, if it exists in the default rule else gets added with the default rule.

You can find my latest changes for this here

Let me know what you think

Trying to include chore commit to the changelog

Hello,
I'm trying to include chore commit to the changelog but I cannot seem to get it working.
I've tried to add custom_release_rules: chore:patch to the setup but without luck.

Any advices?

Thanks a lot,

Annotation count up

Hello Mathieu,

I'm using the github-tag-action with annotated tags as following:

  • name: Bump version and push tag
    id: tag_version
    uses: mathieudutour/[email protected]
    with:
    github_token: ${{ secrets.GITHUB_TOKEN }}
    release_branches: master, RC
    create_annotated_tag: true

I get also release-tags like this:
$ git tag -l
v0.8.0-RC.0
v1.0.0-RC.0
v1.0.1-RC.0
v1.0.2-RC.0
v1.0.3-RC.0
v1.0.4-RC.0

As you can see the annotation does'nt count up (RC.0).
Is this what is expected? Because then I don't know why there is a trailing number (.0).
My expectation is actually that RC.n will count up.

Thanks

Commits analysed repeatedly, affecting version bump multiple times.

Hi Mathieu,

I noticed that when working on a pre-release branch and committing progress to that branch, it's constantly recalculating the new version based on already analyzed commits.

This happens because commits for analysis are always calculated based on the latestTag regardless of where are we "standing" on. (https://github.com/mathieudutour/github-tag-action/blob/master/src/action.ts#L66)

Please confirm if this is the expected behavior? If not, i believe the action should be aware of the context and determine the commits based on that context, so that it actually calculates the right commit diff and bump based only on those.

Please find the evidence here:

  1. https://github.com/andres99x/submodule/actions/runs/594033597
  2. https://github.com/andres99x/submodule/actions/runs/594037850
  3. https://github.com/andres99x/submodule/actions/runs/594043298

The first action contains a patch and a minor commit, while the other two contains commits that shouldn't match a release type, but regardless of this each action execution bumps the version by a minor.

Support pre-releases

It would be nice to have support for pre-releases. I tend to pre-release everything that is not on master (my release branch) by using the same functionality that is used for creating releases except tagging them with a pre-release tag of choice according to the semver 2.0.0 specification https://semver.org/#spec-item-9.

Suggestion:

  • Add a pre_release_branches input that similar to release_branches specifies which branches should be treated as pre-releases. Default to no branches in order to not break current behaviour.
  • Add a append_to_pre_release_tag input to define what should be appended to the pre-release tag according to semver 2.0.0 specification https://semver.org/#spec-item-9

Versioning release branches should follow the latest version from any pre-releases on the branch being merged into the release branch.

v5 README on marketplace includes custom_release_rules input, but not actually recognized as input

Hello,

First, I'd like to thank you for your great work and the functionality you have provided with this action.

I recently wanted to make use of the "custom_release_rules" input. It is documented in the README as well as it seems to be available already as it appears on the action details in the marketplace.

However, I get a warning in the workflow indicating the input is not valid.

When will this be available?

Thanks!
screenshot

Minor & Major version upgrade don't work

Yaml file configuration:

name: Auto Release
on:
  push:
    branches:
      - test
jobs:
  build:
    runs-on: ubuntu-latest
    steps: 
      - uses: actions/checkout@v2
        with:
          fetch-depth: 0
      - name: Bump Version
        id: tag_version
        uses: mathieudutour/[email protected]
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          release_branches: test
          create_annotated_tag: true
      - name: 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 }}

Commit message:

feat: minor release

Github Action log:

##[debug]Evaluating condition for step: 'Bump Version'
##[debug]Evaluating: success()
##[debug]Evaluating success:
##[debug]=> true
##[debug]Result: true
##[debug]Starting: Bump Version
##[debug]Loading inputs
##[debug]Evaluating: secrets.GITHUB_TOKEN
##[debug]Evaluating Index:
##[debug]..Evaluating secrets:
##[debug]..=> Object
##[debug]..Evaluating String:
##[debug]..=> 'GITHUB_TOKEN'
##[debug]=> '***'
##[debug]Result: '***'
##[debug]Loading env
Run mathieudutour/[email protected]
  with:
    github_token: ***
    release_branches: test
    create_annotated_tag: true
    default_bump: patch
    tag_prefix: v
    dry_run: false
##[debug]Found Valid Tag: v0.0.6.
##[debug]Found Valid Tag: v0.0.5.
##[debug]Found Valid Tag: v0.0.4.
##[debug]Found Valid Tag: v0.0.4-test.0.
##[debug]Found Valid Tag: v0.0.3-test.0.
##[debug]Found Valid Tag: v0.0.2-test.0.
##[debug]Found Valid Tag: v0.0.1-test.0.
Previous tag was 0.0.6.
::set-output name=previous_tag::0.0.6
##[debug]steps.tag_version.outputs.previous_tag='0.0.6'
Analysis of 0 commits complete: no release
New version is 0.0.7.
::set-output name=new_version::0.0.7
##[debug]steps.tag_version.outputs.new_version='0.0.7'
New tag after applying prefix is v0.0.7.
::set-output name=new_tag::v0.0.7
##[debug]steps.tag_version.outputs.new_tag='v0.0.7'
...
##[debug]
##[debug]
##[debug]
##[debug]'
##[debug]Creating annotated tag.
##[debug]Pushing new tag to the repo.
##[debug]Node Action run completed with exit code 0
##[debug]Finishing: Bump Version

The minor version stays with no change.

Permissions required by action

Hi!

I would like to try using the action with a custom secret with custom permissions, so I would like to know which permissions from the GITHUB_TOKEN, does this action require ?

Custom custom_release_rules doesn't work for me

Hey!
I don't like that feat by default iterate minor tag and decided to redo this, so I introduced custom keywords + rewrote AngularJS convetions because chore: and style: not rendered for me. But anyway I receive empty changelog body and simple patch increment
Code:

  calculate-next-tag:
    name: "Calculate next tag"
    runs-on: [self-hosted, linux]
    outputs:
      new_tag: ${{ steps.tag_version.outputs.new_tag }}
      changelog: ${{ steps.tag_version.outputs.changelog }}
    steps:
      - name: Bump version and push tag
        id: tag_version
        uses: mathieudutour/[email protected]
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          release_branches: tag-rework
          custom_release_rules: |
            bug:patch:Bug Fixes,
            chore:patch:Chores,
            feat:patch:New Functionality,
            perf:patch:Performance Improvement,
            ci:patch:Continuous Integration,
            docs:patch:Documentation Improvement,
            style:patch:Code Style,
            refactor:patch:Refactoring/TODO's,
            test:patch:Tests,
            minor_upd:minor:Minor Update,
            major_upd:major:Major Update,

Commit msg:
major_upd: Testing major upd

Shouldn't this action trigger "release" event ?

I am testing a separate CD job and have added to it a condition to execute only when on push to master, the "release" event is also triggered.

on: 
  push:
    branches:
      - master
  pull_request:
    branches:
      - master

jobs:
  ci:
    ...
  cd:
    if: github.event_name == 'push' && github.event_name == 'release'

As far as I understand, tag generators have the role to trigger the release event, so you can use it further down your workflow if you need to.

Does this one do that or I have misunderstood the process, in which case how should I go about it ?

`feat!: some breaking change` format isn't working

Spec number 13 from https://www.conventionalcommits.org/en/v1.0.0/:

If included in the type/scope prefix, breaking changes MUST be indicated by a ! immediately before the :. If ! is used, BREAKING CHANGE: MAY be omitted from the footer section, and the commit description SHALL be used to describe the breaking change.

However, using feat! as a prefix, results in a PATCH release, not a MAJOR

Tried using a custom prefix mapping, but the expressions used to parse it seems to be dropping it due to the ! and still resulted in a patch release.

I understand that this action is based off Angular's convention... so if you feel it's out of scope to make this change, I won't fight you :P

bug: unable to parse git ref for pull requests

I'm attempting to create a workflow which compares the version in a project file against what the generated next version will be. This is to ensure that devs have updated the version to match appropriately.
However, this action expects to only run on a branch build and results in this error:

Error: 1.0.1-refs/pull/20/merge.0 is not a valid semver.

Having trouble bumping tags

Hi,

Thank you for creating this Github action! In particular I like the prefix functionality that I couldn't find in other Github Actions. Having a little trouble getting the Semver bumps to work though.

Here's my Action workflow

- name: Bump version and push tag
        id: tag_version
        uses: mathieudutour/github-tag-action@v5
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          tag_prefix: graphqlv
          default_bump: patch

My last release was 0.1.0, and I pushed a commit with the message fix(graphql): Remove Grpc code from graphql (#89). The Action analyzes the commit messages past the previous release and sees a previous commit: feat(graphql): removed line from test.

So it decides to make a minor release, but still doesn't bump. I keep running into Error Reference already exists. Am I doing something wrong?

* Remove protos
The release type for the commit is patch
Analyzing commit: feat(graphql): removed line from test
The release type for the commit is minor
Analyzing commit: fix(graphql): Remove proto
The release type for the commit is patch
Analyzing commit: remove grpc module
The commit should not trigger a release
Analyzing commit: fix(graphql): Remove Grpc code from graphql (#89)

* Remove grpc

* Fixed tests
The release type for the commit is patch
Analysis of 26 commits complete: minor release
New version is 0.1.0.
New tag after applying prefix is graphqlv0.1.0.
Changelog is # [0.1.0](https://github.com/mintothejoo/puffin/compare/v0.0.11...graphqlv0.1.0) (2020-12-08)

### Bug Fixes

* **graphql:** migrate remaining trip controller code ([#88](https://github.com/mintothejoo/puffin/issues/88)) ([c724396](https://github.com/mintothejoo/puffin/commit/c724396027d7953ce1b808a82844b1a783e4434d))
* **graphql:** Remove Grpc code from graphql ([#89](https://github.com/mintothejoo/puffin/issues/89)) ([04285cd](https://github.com/mintothejoo/puffin/commit/04285cd82741a29015718daf2ddbb6cd84af07b2))
* **graphql:** Remove proto ([8df386f](https://github.com/mintothejoo/puffin/commit/8df386f3651bac8b6bf87e2569db4404ecd7c2b5))


### Features

* **graphql:** removed line from test ([6cd5f0c](https://github.com/mintothejoo/puffin/commit/6cd5f0c95899704fa92bbc227ee77742dc97487c))

.
Error: Reference already exists

v5.1 doesn't generate tags

Dependabot suggested I upgrade from v5 to v5.1 and following the upgrade I get...

2020-11-25T07:30:43.9712609Z ##[group]Run mathieudutour/[email protected]
2020-11-25T07:30:43.9713244Z with:
2020-11-25T07:30:43.9714368Z   github_token: ***
2020-11-25T07:30:43.9714710Z   release_branches: main
2020-11-25T07:30:43.9715050Z   default_bump: patch
2020-11-25T07:30:43.9715367Z   tag_prefix: v
2020-11-25T07:30:43.9715694Z   create_annotated_tag: false
2020-11-25T07:30:43.9716017Z   dry_run: false
2020-11-25T07:30:43.9716311Z ##[endgroup]
2020-11-25T07:30:44.2027246Z ##[group]Run actions/create-release@v1
2020-11-25T07:30:44.2027669Z with:
2020-11-25T07:30:44.2028034Z   release_name: Release 
2020-11-25T07:30:44.2028397Z   draft: false
2020-11-25T07:30:44.2028758Z   prerelease: false
2020-11-25T07:30:44.2029085Z env:
2020-11-25T07:30:44.2029841Z   GITHUB_TOKEN: ***
2020-11-25T07:30:44.2030175Z ##[endgroup]
2020-11-25T07:30:44.2796025Z ##[error]Input required and not supplied: tag_name

when I downgrade to v5 again, it works perfectly.
There is no new tag created via v5.1

Always dry_runs, never creates new versions

Hi, are you still working on this? I wasn't able to get the action to actually create a tag or bump the version.

My invocation is

    - name: Bump version and push tag
      id: semanticversion
      uses: mathieudutour/[email protected]
      with:
        release_branches: test-semantic-release
        github_token: ${{ secrets.GITHUB_TOKEN }}
        dry_run: 0

(I tried various variants of dry_run, like leaving it out and false)

But the runs always exhibit two problems: all commits are classified as "should not trigger a release" and it always assumes dry_run. Here is an example output:

2020-05-06T15:24:10.2693513Z ##[group]Run mathieudutour/[email protected]
2020-05-06T15:24:10.2693772Z with:
2020-05-06T15:24:10.2693993Z   release_branches: test-semantic-release
2020-05-06T15:24:10.2694829Z   github_token: ***
2020-05-06T15:24:10.2695053Z   default_bump: patch
2020-05-06T15:24:10.2695261Z   dry_run: 0
2020-05-06T15:24:10.2695463Z   tag_prefix: v
2020-05-06T15:24:10.2695675Z   create_annotated_tag: false
2020-05-06T15:24:10.2695886Z ##[endgroup]
2020-05-06T15:24:10.9770208Z [command]git fetch --tags
2020-05-06T15:24:10.9771139Z fatal: could not read Username for 'https://github.com': No such device or address
2020-05-06T15:24:10.9771561Z [command]git tag
2020-05-06T15:24:10.9771985Z build-number-4
2020-05-06T15:24:10.9772203Z v0.1.0
2020-05-06T15:24:10.9772599Z [command]git rev-list --tags --topo-order --max-count=1
2020-05-06T15:24:10.9773018Z 5c5f3a6ad99850de6ed2b0693e3a3a86554b8a26
2020-05-06T15:24:10.9773592Z [command]git describe --tags 5c5f3a6ad99850de6ed2b0693e3a3a86554b8a26
2020-05-06T15:24:10.9774422Z v0.1.0
2020-05-06T15:24:10.9775071Z [command]git log v0.1.0..HEAD --pretty=format:'%s%n%b==============================================' --abbrev-commit
2020-05-06T15:24:10.9775614Z 'Minimize the rest
2020-05-06T15:24:10.9776138Z =============================================='
2020-05-06T15:24:10.9776621Z 'Dunno
2020-05-06T15:24:10.9777135Z =============================================='
2020-05-06T15:24:10.9777615Z 'Huh?
2020-05-06T15:24:10.9778130Z =============================================='
2020-05-06T15:24:10.9778625Z 'feat: no dry run
2020-05-06T15:24:10.9779141Z =============================================='
2020-05-06T15:24:10.9779639Z 'Use different tool
2020-05-06T15:24:10.9780153Z =============================================='
2020-05-06T15:24:10.9780680Z 'Do I get a new version here?
2020-05-06T15:24:10.9781203Z =============================================='
2020-05-06T15:24:10.9781702Z 'fix: use proper variable
2020-05-06T15:24:10.9782236Z =============================================='
2020-05-06T15:24:10.9782724Z 'Not now
2020-05-06T15:24:10.9783286Z =============================================='Analyzing commit: Minimize the rest
2020-05-06T15:24:10.9783663Z The commit should not trigger a release
2020-05-06T15:24:10.9784004Z Analyzing commit: 
2020-05-06T15:24:10.9784388Z 'Donno
2020-05-06T15:24:10.9784608Z The commit should not trigger a release
2020-05-06T15:24:10.9784822Z Analyzing commit: 
2020-05-06T15:24:10.9785292Z 'Huh?
2020-05-06T15:24:10.9785661Z The commit should not trigger a release
2020-05-06T15:24:10.9786314Z Analyzing commit: 
2020-05-06T15:24:10.9786699Z 'feat: no dry run
2020-05-06T15:24:10.9786918Z The commit should not trigger a release
2020-05-06T15:24:10.9787284Z Analyzing commit: 
2020-05-06T15:24:10.9787679Z 'Use different tool
2020-05-06T15:24:10.9787904Z The commit should not trigger a release
2020-05-06T15:24:10.9788355Z Analyzing commit: 
2020-05-06T15:24:10.9788738Z 'Do I get a new version here?
2020-05-06T15:24:10.9788999Z The commit should not trigger a release
2020-05-06T15:24:10.9789217Z Analyzing commit: 
2020-05-06T15:24:10.9789724Z 'fix: use proper variable
2020-05-06T15:24:10.9789959Z The commit should not trigger a release
2020-05-06T15:24:10.9790303Z Analyzing commit: 
2020-05-06T15:24:10.9790687Z 'Not now
2020-05-06T15:24:10.9790911Z The commit should not trigger a release
2020-05-06T15:24:10.9791138Z Analysis of 8 commits complete: no release
2020-05-06T15:24:10.9822559Z [command]git tag -l v0.1.1
2020-05-06T15:24:10.9823028Z Dry run: not performing tag action.

I had a quick look at the code and didn't see an obvious reason for the issue with dry_run. Also, the commit-analyzer from semantic-release seems Ok. But maybe you do have an idea what's going on.

Unable to bump major or minor version

Hi,

How can I bump the major or minor version with your action?
The patch level is bumping as expected, but this is default behaviour, all attempts to bump major or minor versions are just resulting in a patch level bump...
I tried the examples from the readme (e.g.: feat(deploy_scripts): update script), but this does not work.

my script code is as follows:

# Generate build nummer on each push to every branch, this will be used to generate tags and releases when merged into master.
name: Update buildnumber

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@master
      - name: Bump version and push tag - new
        id: buildnumber
        uses: mathieudutour/github-tag-action@v3
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
      - name: Print new version number.
        env:
          version_number: ${{ steps.buildnumber.outputs.new_tag }}
        run: echo $version_number

Any idea what's going wrong here?
Thanks!

Seems to only analyze the most recent commit message

When I have a PR open, I often add several commits to it -- some may be fixes, some chores, some features etc. I expect that when I merge the PR, this action will look through all commits involved in the PR and make the tag appropriately. However, it seems to only be looking at the last commit, which is invariably something like Merge pull request #21 from steven-murray/unit-tests, and doesn't trigger a release.

An example: https://github.com/steven-murray/halomod/runs/808118417?check_suite_focus=true

For simplicity the important part of that log:

/usr/bin/git tag
1.1.6
1.4.2
v1-hod-cosmology
v1.4.3
v1.4.4
v1.4.5
/usr/bin/git rev-list --tags --topo-order --max-count=1
735c38ea14c3154b4ce7db7c0b8811eba0db365d
/usr/bin/git describe --tags 735c38ea14c3154b4ce7db7c0b8811eba0db365d
v1.4.5
/usr/bin/git log v1.4.5..HEAD --pretty=format:'%s%n%b==============================================' --abbrev-commit
'Merge pull request #21 from steven-murray/unit-tests
Add Unit Tests=============================================='::debug::Setting previous_tag to: v1.4.5
Analyzing commit: Merge pull request #21 from steven-murray/unit-tests
Add Unit Tests
The commit should not trigger a release
Analysis of 1 commits complete: no release

My gitlog:

8d5036f (origin/master, master) Merge pull request #21 from steven-murray/unit-tests
eac59e4 (origin/unit-tests) fix: update hmf to 3.1
4f1e70c feat: add the ability to define halo radius at a particular redshift (or not)
3ada827 fix: require hankel
107f0a0 test: test against data from Florian Beutler and hmcode
15497bb test: test against data from Chris Blake
affef84 test: add regression test data and tests
68d539d test: add 6 tests of bias vs colossus
980e064 feat: class factory for creating COLOSSUS bias functions
7f980fe test: test angular correlation function
9c36310 test: re-implement projected corr tests
c76fb86 test: add 1halo power test for cross_corr
6a06cc1 test: trivial tests of cross_corr
257431d test: add wdm tests and fix low-k u(k,m) tests
627e64f Added tools tests

Tag is always vnull

Hi there,

I've got this action in use in the following way, I'm trying to create a tag based on commit messages like this one:

fix(prod-releases): uses the output of the tagging process as the input of the release phase

And here's my action in use:

- name: Bump version and push tag
  id: create_tag
  uses: mathieudutour/[email protected]
  with:
    github_token: ${{ secrets.GITHUB_TOKEN }}
    release_branches: dev

And here's the output:

Run mathieudutour/[email protected]
/usr/bin/git fetch --tags
/usr/bin/git tag
refs/heads/dev
refs/pull/44/merge
v1.0.0
v1.1.0
v1.2.0
vnull
/usr/bin/git rev-list --tags --topo-order --max-count=1
673a23637907bac23d3998cbdcb5b98a8751d106
/usr/bin/git describe --tags 673a23637907bac23d3998cbdcb5b98a8751d106
vnull
/usr/bin/git log vnull..HEAD --pretty=format:'%s%n%b|commit-hash:%h==============================================' --abbrev-commit
'fix(prod-releases): uses the output of the tagging process as the input of the release phase
|commit-hash:933de6a=============================================='::debug::Setting previous_tag to: vnull
Analyzing commit: fix(prod-releases): uses the output of the tagging process as the input of the release phase
The release type for the commit is patch
Analysis of 1 commits complete: patch release
/usr/bin/git tag -l vnull
vnull

Not sure what I should do about this. Any thoughts?

Semver not upgrading to correct version, defaulting to 0.0.1 everytime

Hi,
I'm using this action as below:

- name: Bump version and push tag
uses: mathieudutour/[email protected]
id: semver
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
dry_run: false
create_annotated_tag: true
append_to_pre_release_tag: ci
release_branches: main,master

So far it had created three release versions from master (and many pre-release version), the latest being 1.0.3.
For any new push to the master through PR, it's trying to create a new version 0.0.1 since it finds the previous_version as 0.0.0. Below is the log from one of the recent workflow run:

Run mathieudutour/[email protected]
with:
github_token: ***
dry_run: false
create_annotated_tag: true
append_to_pre_release_tag: ci
release_branches: main,master
default_bump: patch
tag_prefix: v
Previous tag was 0.0.0.
Analysis of 0 commits complete: no release
New version is 0.0.1.
New tag after applying prefix is v0.0.1.

Changelog is ## 0.0.1 (2021-01-28)

Is there a way to remove the suffix entirely?

I'd like to remove the suffix from the tag and release name. Ideally the tag and release would be formatted thus: v1.19.1. I'm running this action on pushes to the stable branch and right now the formatting is: v1.19.1-stable.0.

I've tried setting append_to_pre_release_tag to null and "" but of course null just uses the default, and "" isn't one of the available options.

Support main as the default branch

Hi,

Thanks for this action!

Due to historic connotations associated with the word master, people have started renaming their default branch from master to main. GitHub have opted for main but people can any name
https://sfconservancy.org/news/2020/jun/23/gitbranchname/

In order to support this, I propose this action be udpated to take the default branch as an input. It can be left to master as a default for in which can it should be a minor release.
However, if we decide that this action will expect the default branch to be main then in that case it should be a breaking change/major version bump.

So can we set the default branch as an input?
I have updated one of our repositories to have default branch name as main but this action is now not generating the correct version in the form of major.minor.patch anymore. It now suffixes the version with some random text.

I'd appreciate some guidance on this.

git rev-list --tags --max-count=1 can return older tags first

From git docs the git rev-list command returns commits in "reverse chronological order". After doing some git rebaseing I got into a situation where this command didn't return the latest tag but instead returned one before. As a result the action tried to create a tag that already existed.

This could be fixed by changing:

git rev-list --tags --max-count=1

to:

git rev-list --tags --topo-order --max-count=1

Chore still not included in changelog

Hello Mathieu,

Sorry for opening a new issue, but I cannot reopen the older one,
I still cannot get chores to be added to the changelog even using v5.1
Is there anything I should do/setup to have them displayed in the changelog?

Thanks a lot,

Originally posted by @mathieudutour in #50 (comment)

Clarify explicit version bumping

The documentation states for default_bump:

Which type of bump to use when none explicitly provided

So how does one explicitly provide the bump then?

Getting "vnull" as my version every now and then

Hi, thanks for this neat tool.

I am getting (not every time) a tag applied as "vnull". Here's my workflow:

name: Bump Version
on:
  push:
    branches:
      - master
jobs:
  bump-version-and-deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@master
      - name: Bump version and push tag
        uses: mathieudutour/[email protected]
        with:
          github_token: ${{ secrets.bump_version }}
          default_bump: false

Here's a snippet of the output:

3.0.3
v1.3.1
v2.0.0
v2.0.2
v2.0.3
v2.0.3b
v2.0.4
v2.0.5
v3.0.0
v3.0.1
v3.0.10
v3.0.11
v3.0.8
v3.0.9
vnull
/usr/bin/git rev-list --tags --topo-order --max-count=1
c7bcc9de1adf49ff03bf93a9d32e1281996a6ec4
/usr/bin/git describe --tags c7bcc9de1adf49ff03bf93a9d32e1281996a6ec4
vnull
/usr/bin/git log vnull..HEAD --pretty=format:'%s%n%b==============================================' --abbrev-commit
'Merge pull request #66 from steven-murray/fix-setup-cfg
fix: applied changes suggested by @webknjaz=============================================='::debug::Setting previous_tag to: vnull
Analyzing commit: Merge pull request #66 from steven-murray/fix-setup-cfg
fix: applied changes suggested by @webknjaz
The commit should not trigger a release
Analysis of 1 commits complete: no release
/usr/bin/git tag -l vnull
vnull

I can't quite put my finger on what is making this happen?

EDIT: I guess the most likely culprit is me setting default_bump to false. Is there a way to not bump the version if no appropriately tagged commits are found?

use main branch

I wonder if I could use main branch as the master branch.

Only the first commit is correctly analysed

Here is an example:

=============================================='Analyzing commit: fix(build): remove picocli warnings and fix release workflow
The release type for the commit is patch
Analyzing commit: 
'Merge pull request #41 from Atlaoui/pass-args-to-processes
Pass args to processes
The commit should not trigger a release
Analyzing commit: 
'feat: add --version CLI option + version in MANIFEST
The commit should not trigger a release
Analyzing commit: 
'docs: update README examples and CLI docs
The commit should not trigger a release
Analyzing commit: 
'feat: pass args to processes in MPI and in peersim.
The commit should not trigger a release
Analyzing commit: 
'add args optionnal parameters to CLI
The commit should not trigger a release
[...]
Analyzing commit: 
'fix(build): use checkout action v1 to fetch tags
The commit should not trigger a release
Analyzing commit: 
'fix(build): create annotated tags on release
The commit should not trigger a release
Analysis of 31 commits complete: patch release
git tag -l 0.1.3

And the changelog only contains the first commit as well: https://github.com/Atlaoui/ParallelProgramingInterface/releases/tag/0.1.3

Here is the complete build: https://github.com/Atlaoui/ParallelProgramingInterface/runs/711200554?check_suite_focus=true

Support gitmoji commits

Thanks for creating this great action!
I would like to use is with gitmoji based commits like ๐Ÿ“(README): Updated README with info, but it seems not possible with the current separators.
As the above example, which refers to the docs: conventional commits type, can also be represented by :memo:(README): Updated README with info, I thought I can just add them to the custom_release_rules.
Unfortunately, as the separator : is hardcoded here

const releaseTypeSeparator = ':';

it's not possible to add them like :zap::patch, :bug::patch, :ambulance::patch, :sparkles::minor etc..
My suggestion would be to either have optional separators with two new parameters (:zap:,patch; :bug:,patch; ...) or to use another data representation of the custom_release_rules.
What do you think @mathieudutour ?

Action is confused by the other tags

Problem

I'm running the action on the repo where the recent tags aren't in the semver format \d+\.\d+\.\d+.
E.g. there's v2.0.0 (starts with v), a/b/c/d/e (letters), 123123123 (just digits).

I'm expecting the action to find and bump the tag that's in the right format but that isn't the most recent: 10.10.10.

The action correctly find it, but when it tries to bump the version, it ends up with 10.10.11-refs/tags/v2.0.0.0 and fails.

Action log

Run mathieudutour/[email protected]
  with:
    github_token: ***
    default_bump: patch
    release_branches: master,main
    create_annotated_tag: false
    dry_run: false
Previous tag was 10.10.10, previous version was 10.10.10.                  <-- found the right tag to bump 
Analyzing commit: Update ci.yml
The commit should not trigger a release
Analyzing commit: Update ci.yml
The commit should not trigger a release
Analyzing commit: Update ci.yml
The commit should not trigger a release
Analyzing commit: Update ci.yml
The commit should not trigger a release
Analyzing commit: r:x
The commit should not trigger a release
Analysis of 5 commits complete: no release
Error: 10.10.11-refs/tags/v2.0.0.0 is not a valid semver.                  <-- weird result of the bump

Tags in the repo

$ git for-each-ref --sort=-v:refname

4a91d1d7c66bacc8a8e1217bafddeadba216a69b commit	refs/tags/v2.0.0
c3dfda08a6968213f6176fc5f3a275a816caf8a8 commit	refs/tags/v1.0.0
6da577d61edfd17941b5ad91e97ec66bbcf54ae7 commit	refs/tags/a/b/c/d/e
f02c883fdb274dcde9b28c0f8ba34b60bdf72c43 commit	refs/tags/123123123
6da577d61edfd17941b5ad91e97ec66bbcf54ae7 commit	refs/tags/10.10.10
6da577d61edfd17941b5ad91e97ec66bbcf54ae7 commit	refs/tags/10.10.8
6da577d61edfd17941b5ad91e97ec66bbcf54ae7 commit	refs/tags/10.10.1
6da577d61edfd17941b5ad91e97ec66bbcf54ae7 commit	refs/tags/10.6.9
6da577d61edfd17941b5ad91e97ec66bbcf54ae7 commit	refs/tags/10.0.0
6da577d61edfd17941b5ad91e97ec66bbcf54ae7 commit	refs/tags/2.0.100
6da577d61edfd17941b5ad91e97ec66bbcf54ae7 commit	refs/tags/2.0.0
062ae2a2624bbdd4a5341fee5a78fad944e96804 tag	refs/tags/1.1.1
f02c883fdb274dcde9b28c0f8ba34b60bdf72c43 commit	refs/tags/1.1.0
ede7d8d7268e84d738e9801a368a86d9a8cb47d7 commit	refs/tags/1.0.0
1e93f600f4b4320f2f09ef8754de1e782a3a901c commit	refs/tags/0.2.0
3c7bd2d8f5b95a752060d51c6673c36b192659dc commit	refs/tags/0.1.2
80dfeecb5312bb897ab83c5fd81ad007ec5d1a37 commit	refs/tags/0.1.1
12f0ef7b37c33f3ae6271e69b3fb1d0936d3a2f4 commit	refs/tags/0.1.0
c3dfda08a6968213f6176fc5f3a275a816caf8a8 commit	refs/remotes/origin/master
4a91d1d7c66bacc8a8e1217bafddeadba216a69b commit	refs/heads/master

Tag version removed entirely

My build was referencing v3 of your action and suddenly the tag has been removed or renamed. Is there intent moving forward that tags / release will be immutable?

Please create a new release for the latest change

I inputted "custom_tag" and get the error

##[warning]Unexpected input(s) 'custom_tag', valid inputs are ['github_token', 'default_bump', 'tag_prefix', 'release_branches', 'create_annotated_tag', 'dry_run']

since the "custom_tag" feature is not in the v4.5 release.

Version inside package.json not updated

This workflow module works fine with the patch, minor and major releases.
The tags and release are generated correctly
However, the version inside package.json is not updated. For example, I did a Major release 1.0.0 - Release v1.0.0

The version inside package.json is not updating:

{
  "name": "mob-example",
  "version": "0.1.0"
}

Is this expected to behave this way? Ideally, your package.json version should be in sync with your current release version.

[Feature Request] Allow explicitly supplying previous tag

Some projects don't support semver due to platform limitation. Allowing those projects to explicitly provide previous tag in semver format will be helpful. That way these projects can do a dry run to get next semver version and convert it to their previous versioning schemes.

Bump RC version number on the right at pre_release_branches.

Hi everyone,
I use composer, and I need to bump the RC version as default behavior on prerelease branches.

Expected
v1.1-RC1
v1.1-RC2

Actual Output:
v1.1-RC.0
v1.2-RC.0

Do we have a specific way to do that?
Could be responsibility of the dev to explicitly say what they want to create as a RC, but will be fine if default is RC${n}

Implementation:

  • name: Tag Bump version and push tag
    id: tag_version
    uses: mathieudutour/[email protected]
    with:
    github_token: ${{ secrets.GITHUB_TOKEN }}
    pre_release_branches: staging
    append_to_pre_release_tag: RC

output 2 runs
v1.1-RC.0
v1.2-RC.0

Any recommendations?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.