anothrnick / github-tag-action Goto Github PK
View Code? Open in Web Editor NEWA Github Action to tag a repo on merge.
License: MIT License
A Github Action to tag a repo on merge.
License: MIT License
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.
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
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:
Can you tell me what you think?
Best regards
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?
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?
{
"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
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
.
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?
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.
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.
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.
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.
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!
Is the tag stored in some env variable? Is there a way to extract the current tag that we are setting ?
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
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 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 }
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
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.
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.
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:
Version 1.13.0
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?
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.
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
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?
Are there any immediate plans to support running on Windows? If, any recommendations for alternatives?
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.
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:
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
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
Hello,
Will you support the creation of an annotated tag, including message specification, rather than lightweight one?
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.
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
Is it possible to bump with tag version that contains rc
suffix for eg: 1.0.0-rc
. If yes, how is it possible?
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)
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?
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;
}
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.
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.
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!
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
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.
I'm not sure if I'm just not doing this right. My workflow is:
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?
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.
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
# ...
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?
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
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 }
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!!
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.