Would it be possible to support a body to the tag? I use this action with a custom tag to push a new version tag to the repo but would love to add release notes as a body.

I tried adding #major and #patch tags to the body of my commit message for version 1.13.0 but it still released a minor version.

My env vars were:

GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
WITH_V: true
DRY_RUN: true

What I'm trying to do is use this action to tag each push to our develop branch with an incremental build id so users can download artifacts on PR merge.

I've created a tag, 0.5.0-1, and I have the following workflow definition (github-actions-attempt-2 is my testing branch for now) checked in:

name: Tag commits on develop

on:
  push:
    branches:
      - develop
      - github-actions-attempt-2

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@master
      - name: Bump version and push tag
        uses: anothrNick/github-tag-action@master
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          DEFAULT_BUMP: build
          RELEASE_BRANCHES: develop,github-actions-attempt-2

I see the action run successfully, but I'm not seeing a new tag created, and when I look at the output for the action I'm seeing the help output from the semver script instead.

What is the proper DEFAULT_BUMP value to use and what format should our tags use to support bumping the build number only?

Hi I'm trying to use this action as part of our build process and it's only ever bumping us on the minor version.

You can see an example of a commit that didn't trigger a minor increase

cds-snc/c19-benefits-node@982a0ac

Here is the action that runs on push to master
https://github.com/cds-snc/c19-benefits-node/blob/master/.github/workflows/build-deploy-dev.yml

Are there any immediate plans to support running on Windows? If, any recommendations for alternatives?

Up until now, I have been using this action with great success, using GitHub's own runners.
When experimenting with using my home server as a self-hosted runner, I ran into an issue with this action.

The action itself succeeds, but it fails to push a tag and shows a few errors in the logs:

*** CONFIGURATION ***
	DEFAULT_BUMP: PATCH
	WITH_V: false
	RELEASE_BRANCHES: master
	CUSTOM_TAG: 
	SOURCE: .
	DRY_RUN: false
	INITIAL_VERSION: 0.0.0
	TAG_CONTEXT: repo
	PRERELEASE_SUFFIX: testing
	VERBOSE: true
fatal: not a git repository (or any parent up to mount point /github)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
Is master a match for 
pre_release = true
fatal: not a git repository (or any parent up to mount point /github)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
fatal: not a git repository (or any parent up to mount point /github)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
fatal: not a git repository (or any parent up to mount point /github)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
fatal: not a git repository (or any parent up to mount point /github)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
fatal: not a git repository (or any parent up to mount point /github)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
fatal: not a git repository (or any parent up to mount point /github)
No new commits since previous tag. Skipping...
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).

I am personally fine just using GitHub's own runners, but in case you are interested in looking into it:

I run the runner on my home server in docker. It uses the docker image tcardonne/github-runner:latest.
If any necessary information is missing, I'd be happy to provide.

Hi,
tag not being created with message:
No new commits since previous tag. Skipping...
workflow was triggered manually with workflow_dispatch, and there was no new commits in branch but doc's says:

• If triggered on your repo's default branch (master if unchanged), the bump version will be a release tag.
  so as i understand if job was manually triggered via workflow_dispatch and there were no new commits new TAG should be created?
  action settings:
  *** CONFIGURATION ***
  DEFAULT_BUMP: minor
  WITH_V: true
  RELEASE_BRANCHES: master
  CUSTOM_TAG:
  SOURCE: .
  DRY_RUN: false
  INITIAL_VERSION: 0.0.0
  TAG_CONTEXT: repo
  PRERELEASE_SUFFIX: beta
  VERBOSE: true

Try to run this action locally using https://github.com/nektos/act. But it fails with:

| *** CONFIGURATION ***
|       DEFAULT_BUMP: patch
|       WITH_V: true
|       RELEASE_BRANCHES: main
|       CUSTOM_TAG: 
|       SOURCE: .
|       DRY_RUN: false
|       INITIAL_VERSION: 0.0.0
|       TAG_CONTEXT: repo
|       PRERELEASE_SUFFIX: beta
|       VERBOSE: true
| Is main a match for deployments-ci
| pre_release = true
| error: cannot run ssh: No such file or directory
| fatal: unable to fork
| fatal: ambiguous argument '0.0.0': unknown revision or path not in the working tree.
....
| pre-patch
| Bumping tag 0.0.0. 
|       New tag v0.0.1-beta.1
[Hasura dev deploy/Deploy to dev cluster]   ⚙  ::set-output:: new_tag=v0.0.1-beta.1
[Hasura dev deploy/Deploy to dev cluster]   ⚙  ::set-output:: part=pre-patch
[Hasura dev deploy/Deploy to dev cluster]   ⚙  ::set-output:: tag=v0.0.1-beta.1
| 2021-01-26T11:27:11Z: **pushing tag v0.0.1-beta.1 to repo duneanalytics/core
[Hasura dev deploy/Deploy to dev cluster]   💬  ::debug::
[Hasura dev deploy/Deploy to dev cluster]   ❗  ::error::Tag was not created properly.
[Hasura dev deploy/Deploy to dev cluster]   ❌  Failure - Bump version and push tag

Any ideas anyone?

The issue that I am facing is that when i run this action on a test branch with the release branches variable set a new tag is generated fine. However on master when my workflow is triggered on a schedule, the action seems to not push the tag and silently the workflow fails with no error message. Am I missing something?

Is the tag stored in some env variable? Is there a way to extract the current tag that we are setting ?

Thanks for this nice little action.

While it does a good job, I find that the current version allows only to tag a commit but not to determine a new tag without actually tagging the commit.

However, when I want to tag a npm release, I need to update and commit the package.json beforehand. This would require to first create the new tag, do some extra steps that end with a commit and finally tag that additional commit.

In the workflow I would like to do something like this:

steps: 
# ...
- uses: anothrNick/[email protected]
   id: tagger
   env:
     GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
     DRY_RUN: true
- run: npm version ${{ steps.tagger.outputs.new_tag }}
  if: steps.tagger.outputs.new_tag != ""
- use: some-fancy/commit-action@latest
  if: steps.tagger.outputs.new_tag != ""
  with:
    message: Version Bump
- uses: anothrNick/[email protected]
  if: steps.tagger.outputs.new_tag != ""
   env:
     GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
     WITH_V: true
# ...

Since Github has changed the default branch to main, so now this action is not working as expected, it creates tag with vMAJOR.MINOR.PATCH-beta.1 whereas I don't want beta-1, I have added main in my RELEASE_BRANCHES as well, but still it doesn't work..

This is my Github action workflow for main branch
https://github.com/kahootali/dotnet-core-github-actions/blob/main/.github/workflows/main.yml

And this is the repo link, that I am trying to add this action to.

https://github.com/kahootali/dotnet-core-github-actions

It would be great to have the possibility to disable automatic bumping and only have manual bumping.

Maybe solvable by allowing a DEFAULT_BUMP=none case?

When I set the action trigger at push it works fine, but invoking it withing a cron the action fails with this error : ##[error]Docker run failed with exit code 6

My workflow yml:

on: 
  schedule:
    - cron:  '*/5 * * * *'

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@master
    - name: Bump version and push tag
      uses: anothrNick/github-tag-action@master
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        RELEASE_BRANCHES: master
        DEFAULT_BUMP: patch

This action can run on any number of branches, but the action always looks for the latest tag and bumps that: https://github.com/anothrNick/github-tag-action/blob/master/entrypoint.sh#L28

Instead, look at the ref of the branch that triggered the action (e.g. via git describe) and bump that.

When we don't have any initial release Tag in master (e.g. no v0.0.0 in master), the first merge in another branch creates a v0.1.0-beta.1 tag which is good. However on the second merge to another branch the bump version failed because it tries again to create a v0.1.0-beta.1 tag which already exists. This is due to the fact that the script doesn't found any release tag (e.g. v0.0.0) because it doesn't exist. To solve the issue I had to manually create a tag v0.0.0 on my master branch (I did it on the first commit of master).

If I set DEFAULT_BUMP to none in my actions.yml and don't include #major, #minor or #patch in the commit message, I get a failed step with the below error message. It looks like it's trying to push a tag 'refs/tags/Default bump was set to none. Skipping...' when it should be skipping this entirely?

Default bump was set to none. Skipping...
fatal: too many params
2020-08-18T11:37:53Z: **pushing tag Default bump was set to none. Skipping... to repo sarahethompson/actions-test
  "message": "refs/tags/Default bump was set to none. Skipping... is not a valid ref name.",
  "documentation_url": "https://docs.github.com/rest/reference/git#create-a-reference"
}

    - name: Bump version and push tag
      uses: anothrNick/[email protected]
      env:
        GITHUB_TOKEN: ${{ secrets.SARAH_ACTIONS_PAT }}
        DEFAULT_BUMP: none
        TAG_CONTEXT: branch
        RELEASE_BRANCHES: release/.*,master

Hi, I've just started using this action and I love, thanks for open-source it.

I wanted to ask, is there a way you could support suffixes to the tags? I'd like to add an action on my release-candidate branch and have tags created like 1.0.0-alpha.1, 1.0.0-beta.1 or 1.0.0-rc.1 and increment them on new pushes. At the moment, if the action is triggered as a pre_release, the tag is released as 1.0.0-8618ffc, for instance.

UPDATE
Actually, no tag is created if it's a prerelease:

if $pre_release
then
    echo "This branch is not a release branch. Skipping the tag creation."
    exit 0
fi

We use this action to create a new major version on every merge to master, but since 1.29.0 it keep trying to create the a most recently used tag, in this case 662.0.0.

We've reverted to 1.28.0 and it's working ok again so not sure what changed.

... omitted ...
2020-09-15T17:10:59.2448813Z  * [new tag]           662.0.0                 -> 662.0.0
2020-09-15T17:10:59.2449371Z  * [new tag]           67.0.0                  -> 67.0.0
2020-09-15T17:10:59.2449931Z  * [new tag]           68.0.0                  -> 68.0.0
2020-09-15T17:10:59.2450495Z  * [new tag]           69.0.0                  -> 69.0.0
2020-09-15T17:10:59.2451051Z  * [new tag]           7.0.0                   -> 7.0.0
2020-09-15T17:10:59.2451610Z  * [new tag]           70.0.0                  -> 70.0.0
2020-09-15T17:10:59.2452196Z  * [new tag]           70.100.1                -> 70.100.1
2020-09-15T17:10:59.2452763Z  * [new tag]           70.100.2                -> 70.100.2
2020-09-15T17:10:59.2453349Z  * [new tag]           70.101.1                -> 70.101.1
2020-09-15T17:10:59.2453917Z  * [new tag]           70.101.2                -> 70.101.2
2020-09-15T17:10:59.2454485Z  * [new tag]           70.99.1                 -> 70.99.1
... omitted ...
2020-09-15T17:10:59.2489855Z  * [new tag]           97.0.0                  -> 97.0.0
2020-09-15T17:10:59.2490442Z  * [new tag]           97.114.6                -> 97.114.6
2020-09-15T17:10:59.2491011Z  * [new tag]           97.114.7                -> 97.114.7
2020-09-15T17:10:59.2491578Z  * [new tag]           97.118.3                -> 97.118.3
2020-09-15T17:10:59.2492151Z  * [new tag]           97.118.4                -> 97.118.4
2020-09-15T17:10:59.2492720Z  * [new tag]           97.118.5                -> 97.118.5
2020-09-15T17:10:59.2493288Z  * [new tag]           97.118.6                -> 97.118.6
2020-09-15T17:10:59.2494435Z  * [new tag]           97.119.1                -> 97.119.1
2020-09-15T17:10:59.2495032Z  * [new tag]           98.0.0                  -> 98.0.0
2020-09-15T17:10:59.2495596Z  * [new tag]           99.0.0                  -> 99.0.0
2020-09-15T17:10:59.2496508Z  * [new tag]           99.119.2                -> 99.119.2
2020-09-15T17:10:59.2496956Z Trigger build
2020-09-15T17:10:59.3455660Z major
2020-09-15T17:10:59.3456024Z 662.0.0
2020-09-15T17:10:59.3497649Z fatal: tag '662.0.0' already exists
2020-09-15T17:10:59.3889592Z 2020-09-15T17:10:59Z: **pushing tag 662.0.0 to repo echo-health/prescriptions
2020-09-15T17:10:59.8752362Z   "message": "Reference already exists",
2020-09-15T17:10:59.8755460Z   "documentation_url": "https://docs.github.com/rest/reference/git#create-a-reference"
2020-09-15T17:10:59.8756893Z }

I'd like to have the option to automatically create the release version after the tag has been created. I'd anticipate that some people would want to be able to trigger this from a commit message hashtag. Personally, I'd prefer a boolean toggle:

env:
  CREATE_RELEASE: true

Hi @anothrNick ,

Thanks for this tag action. it's great and I used it on my project.
But it would be nice to add 1 line code for set output value ?
echo ::set-output name=NEW_TAG::$new
So I can grab the new version of tag on another step.

Thanks.

The README on the marketplace appears to be using master as it references things like CUSTOM_TAG but the Use latest version button provides 1.8.0 and none of the versions after that.

Manually referencing later tags works even though they don’t show up under releases.

So I see that there is a PRERELEASE_SUFFIX option available however for my teams tagging convention for Release Branches we use the following format for release candidate labels. I'm wondering if there's a way to accomplish the following:
Branch (1.0.0)

• 1.0.0-rc.1
• 1.0.0-rc.2
• 1.0.0-rc.3
• 1.0.0-rc.4
• 1.0.1 (release version)

Hello,
Will you support the creation of an annotated tag, including message specification, rather than lightweight one?

Currently, when moving all my files into the release folder, the version is appended to both the zip and the containing folder.

release-0.1.0.zip
└───release-0.1.0
    │   file1.foo
    │   file2.foo

Since I'm using this for a plugin, the containing folder has to retain it's name, without the version appended.
I don't want to wrap it into yet another folder, or force users to rename it after unzipping.

Any chance support for that can be added?

Cheers

It would be great if github-tag-action could support operating on a relative path under $GITHUB_WORKSPACE, such as when the actions/checkout action is run with the path setting.

It would be great if we could get the tag from the output regardless of whether or not a new tag was created. That way we don't need to git fetch --tags and git describe --tags in subsequent steps.

Hey there, currently loving the Action for bumping tags. This is more of a feature request / question than it is an issue, so feel free to close it and direct me to a better tracking place if one exists.

Is there a clean way to bump the semver version of an NPM package using the same #major, #minor, #patch keywords from within this Action? Should this be done in an additional step using the setup-node Action?

Any insight is great. Thanks!

Thanks for this action. I've been enjoying this without any problems, ofc.
One feature request is to disable bump when the #none tag is contained in the commit message regardless of DEFAULT_BUMP.

Thanks for this plugin!

It would be great if you could tag this repo with v1 so that I can track the latest safe version rather than having to bump every time you do a non-breaking release!

I guess this could also be a feature request for this plugin, e.g. when I would normally tag my repo with v1.3.4, also tag it with v1.3 and v1.

Happy to look at putting together a PR if you think this would be a helpful addition.

example failing run

{
  "message": "Not Found",
  "documentation_url": "https://docs.github.com/rest/reference/git#create-a-reference"
}

This is how the action is being called:

  create-new-tag:
    needs: test
    name: Create New Git Tag for release
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
      with:
        fetch-depth: '0'
    - name: Bump version and push tag
      uses: anothrNick/[email protected]
      env:
        GITHUB_TOKEN: ${{ secrets.BOT_GITHUB_TOKEN }}
        WITH_V: true
        RELEASE_BRANCHES: master
        DEFAULT_BUMP: patch

I'm not sure if I'm just not doing this right. My workflow is:

1. Make changes in a branch
2. Actions does testing in the branch with each commit
3. When all tests pass and features are done, merge create PR to merge with main
4. When pushing to main, create tag
5. When tag is pushed, trigger a draft release with another action.

The problem I'm running into is Step 5. When using this action, the tag is pushed, it doesn't actually trigger a push event. You can review the logs here

When I manually create the trigger and push it to github, the push is registered and the create-release-draft job fires.

My expectation is that github would see the push and then fire off another invocation of the workflow from the tag. Any idea why it wouldn't?

In the current behavior, this action will find the most recent tag. However it is not guaranteed this will always be a semver tag. This may break things when manual tagging (or tagging via other sources) is done.

Instead, this action should find the largest semver version tag and use that instead.

Problem Description

Noticed something a little odd. The problem is a little complex, but will try to break it down as simply as possible.

I initially started using github-tag-action without the WITH_V option. When my project was at version number 0.1.0 I decided to set the WITH_V option to true. I then pushed a patch and the resulting tag was as expected v0.1.1. I then removed the WITH_V option and pushed another patch and the resulting tag was 0.1.2. I then pushed several more patches, but the version number did not increment and each time I saw the following logs in the workflow:

patch
0.1.2
2020-08-08T23:11:08Z: **pushing tag 0.1.2 to repo ****/****
{
  "message": "Reference already exists",
  "documentation_url": "https://docs.github.com/rest/reference/git#create-a-reference"
}

It seems github-tag-action kept trying to push 0.1.2 even though that version number already existed. Apparently it was picking up v0.1.1 as the latest tag each time. After removing this tag, the problem disappeared.

Currently, this action has optional environment variables to determine the behavior. These should be converted to defined inputs of the action.yml. These are then read in using the with workflow keyword. This is more idiomatic to Github Actions.

https://help.github.com/en/actions/automating-your-workflow-with-github-actions/metadata-syntax-for-github-actions#inputs

https://help.github.com/en/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstepswith

I'm just confused about the phrase Pushes tag to github under Workflow section of your readme.

Once you push the lightweight tag, should it trigger the event on: push: tags: on Github actions too?

I tried using your action (thank you for sharing it). Unfortunately the DRY_RUN env var does not appear to do what it says on the tin.

I set it to true, but in the run it still created a tag on the master branch.

Steps to reproduce:

1. Create a workflow with this action and run the workflow with some new commit
2. Set DRY_RUN to true
3. See tag printed to stdout
4. See tag in Releases tab within the github UI.

Version 1.13.0

I am creating a tag using this action.
And then I have another workflow which uses on push tag to get triggered to create the release, but the release workflow is not getting triggered.

on:
  push:
    tags:
      - v*

jobs:
  create-release:
    if: github.event.base_ref == 'refs/heads/master'
    name: Create Release
    runs-on: ubuntu-latest
    steps:
      - uses: "marvinpinto/action-automatic-releases@latest"
        with:
          repo_token: "${{ secrets.GITHUB_TOKEN }}"
          prerelease: false

Hi, great action btw,

i'm having an issue with the RELEASE_BRANCHES, it appears the regex its not comparing correctly with the name of the branch.
the branch name is release/v1.0.0 for example

this is the current configuration

      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        WITH_V: true
        DEFAULT_BUMP: minor
        INITIAL_VERSION: 1.0.1
        RELEASE_BRANCHES: release/*

in the logs of the action I see the following

Is release/* a match for HEAD
pre_release = true
fatal: could not read Username for 'https://github.com': No such device or address

and at the end

minor
v0.7.0-8668037
This branch is not a release branch. Skipping the tag creation.

Any ideas why it is not recognizing it as a release branch?
thanks!!

If current version is v1.0.1-RC.1, my expectation is that next version should be v1.0.1-RC.2 if default bump is not set. However, the result is v0.21.2-RC.1 instead. Consider this input:

❯ git tag --list --merged HEAD --sort=-v:refname
v1.0.1-RC.1
v0.21.1
...

And from git actions log:

2021-03-17T14:23:15.9953207Z *** CONFIGURATION ***
2021-03-17T14:23:15.9968659Z 	DEFAULT_BUMP: minor
2021-03-17T14:23:15.9976816Z 	WITH_V: true
2021-03-17T14:23:15.9977374Z 	RELEASE_BRANCHES: series/0.x
2021-03-17T14:23:15.9977855Z 	CUSTOM_TAG: 
2021-03-17T14:23:15.9978257Z 	SOURCE: .
2021-03-17T14:23:15.9978661Z 	DRY_RUN: false
2021-03-17T14:23:15.9979106Z 	INITIAL_VERSION: 0.0.0
2021-03-17T14:23:15.9979585Z 	TAG_CONTEXT: branch
2021-03-17T14:23:15.9980076Z 	PRERELEASE_SUFFIX: RC
2021-03-17T14:23:15.9980529Z 	VERBOSE: true
2021-03-17T14:23:16.0026219Z Is series/0.x a match for series/1.x
2021-03-17T14:23:16.0026767Z pre_release = true
2021-03-17T14:23:16.3252720Z Migrate to cats-effect 3 (#45) LICENSE README.md awssdk build.sbt docker-compose.yml dynosaur project scanamo website Migrate to cats-effect 3 Attempt series/1.x release (#65) #patch Make build-series-1.x pre-release (#49) #patch Change release strategy (#48) Change to auto release on 2 branches called series/0.x and series/1.x to
2021-03-17T14:23:16.3254712Z  accommodate parallel releasing features to 0.x and 1.x versions where
2021-03-17T14:23:16.3255595Z  1.x version will be used for cats effect 3. #patch Fix badge URLs (#42) #patch
2021-03-17T14:23:16.4359261Z pre-patch
2021-03-17T14:23:16.4367599Z Bumping tag v1.0.1-RC.1. 
2021-03-17T14:23:16.4368328Z 	New tag v0.21.2-RC.1
2021-03-17T14:23:16.4875002Z 2021-03-17T14:23:16Z: **pushing tag v0.21.2-RC.1 to repo d2a4u/meteor
2021-03-17T14:23:16.9170907Z   "ref": "refs/tags/v0.21.2-RC.1",
2021-03-17T14:23:16.9172131Z   "node_id": "MDM6UmVmMzAwNjIyNjg4OnJlZnMvdGFncy92MC4yMS4yLVJDLjE=",
2021-03-17T14:23:16.9173773Z   "url": "https://api.github.com/repos/d2a4u/meteor/git/refs/tags/v0.21.2-RC.1",
2021-03-17T14:23:16.9174472Z   "object": {
2021-03-17T14:23:16.9175312Z     "sha": "f0fe267fab3ae499ac1e71f14a3e09ff54a32c07",
2021-03-17T14:23:16.9176022Z     "type": "commit",
2021-03-17T14:23:16.9176986Z     "url": "https://api.github.com/repos/d2a4u/meteor/git/commits/f0fe267fab3ae499ac1e71f14a3e09ff54a32c07"
2021-03-17T14:23:16.9177923Z   }
2021-03-17T14:23:16.9178303Z }

Sometimes during workflow it is necessary to checkout master directly in order to complete a workflow.
In these cases this tag action fails, because it uses the $GITHUB_REF environment variable and does not verify if this variable is actually the same as the checked out branch.

In my case I run the following steps after a successful merge action:

steps:
      - uses: actions/checkout@v2
        with:
          ref: master

      - run: |
          git config --local user.email "[email protected]"
          git config --local user.name "GitHub Action"
  
      - uses: anothrNick/[email protected]
        id: tagger
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 

Instead of tagging the latest version, the action complains that This branch is not a release branch. Skipping the tag creation.. Further up the action spits the following logs.

Is master a match for refs/pull/45/merge
pre_release = true

However, at this part of the workflow the checked out branch is actually a release branch and not the ref-branch that triggered the workflow.

Shouldn't the action use the checked out branch rather than relying on the information provided by github?

Love this project, just started using it in a private repo.

Occasionally we trigger this GitHub Action remotely for a blank deploy/re-deploy. It would be great if there was an early-exit check like (pseudocode):

if HEAD == COMMIT {
    echo "Commit already tagged as version $VERSION"
    return 0;
}

Is it possible to bump with tag version that contains rc suffix for eg: 1.0.0-rc. If yes, how is it possible?

I'm using anothrNick/[email protected] and enabled debug mode, the debug message of this line is empty https://github.com/anothrNick/github-tag-action/blob/1.26.0/entrypoint.sh#L151

https://github.com/leo108/geolite2-db/runs/1079131682?check_suite_focus=true

This workflow works well when triggered manually, but always failed when triggered by github action schedule.

Hi
You project is great and I have been looking for something similar for quite some time. I have always been surprised that nobody tackled the automation of the computation of version numbers.
I was about to build mine when I saw your project.

I tried it but I am still missing a few features. Mainly to distinguish tags from the main branch and from other branches I'd be glad to contribute if you accept.

What I am mainly missing is a way to create pre-releases. This would apply mainly in the case of Pull Requests. The idea would be to pass an input (PRE-RELEASE) and in that case, the computation would be the following:

• last tag would filter all pre-releases
• version would be bumped as usual
• patch version would be forced to 0
• version would be postfixed : -SHA where SHA is the short version of the sha of the commit.

Can you tell me what you think?

Best regards

Hey,
First and foremost, great work with this library. I ran into an issue where I wanted to add a prefix to the tag besides "v". Is there any way we can make that change?
Thanks

Hi, thanks for this great GH action!

I'm having an issue with the SOURCE environment variable. I would like to copy only the relevant files to a release folder and release the folder contents. This should exclude folders like .github/ from the release ZIP.

jobs:
  build:
    name: Create Release
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2
        with:
          fetch-depth: '0'
      - name: Create Release Folder
        run: rsync -arv --exclude='.git/' --exclude='.github/' --exclude='.vscode/' --exclude='scripts/' . ./release
      - name: Bump version and push tag
        uses: anothrNick/[email protected]
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          WITH_V: true
          RELEASE_BRANCHES: main,release.*,hotfix.*
          SOURCE: release

Source: https://medium.com/@Keithweaver_/zip-code-base-with-github-actions-for-releases-aca66f530dae

The outcome from this job is a ZIP file with all the file contents in it, including the folders such as .github/. I checked the release folder and it doesn't include the folders that I would like to exclude. Using release or ./release does not make a difference.

Any idea what this could be?

Thanks!

Action is incompatible with latest version of actions/checkout, because they change default fetch behavior, now fetches only the SHA being checked-out. See more.

Now we should manually fetch tags by git fetch --tags
More info

Hi! I have a GitHub workflow set up in one of my repos that uses github-tag-action and it has been working great so far! Yesterday though I wanted to make a minor release of my library so I made a PR and added #minor in the commit message. The previous tag was 0.0.5 and the one created after the workflow ran was 0.0.6 even though I added #minor. You can see my full workflow here: https://github.com/naknut/Combinefall/blob/master/.github/workflows/Create%20Release.yml and my commit here: naknut/Combinefall@7389267

As you can see #minor is in the message but for some reason tag 0.0.6 was created. Did I do something wrong or is this a bug?

Note: If you check the tags now the latest one says 0.1.0 but that is because I manually edited the tag to have the correct semver.

Right now I need to use a second step to calculate the major minor and patch numbers. Would it be possible to add as outputs the Major Minor and Patch values?