github-tag-action icon indicating copy to clipboard operation
github-tag-action copied to clipboard

Release tags are created on pull requests despite having set a release_branch

Open mikael-andersson91 opened this issue 3 years ago • 6 comments

Hi, I am attempting to use this action as part of a workflow that is triggered both on push and pull_request events on for my main branch with the following inputs:

steps:
  - uses: actions/checkout@v3
  
  - name: Bump version and push tag
    id: tag_version
    uses: mathieudutour/[email protected]
    with:
      github_token: ${{ secrets.GITHUB_TOKEN }}
      release_branches: main

The issue here comes when I run the workflow on pull requests a release tag is always created, despite having specified main as my only release branch. My understanding of the input documentation copied below is that pull requests would generate a version number with the commit hash as a suffix and not generate a tag, while push on release branch would generate a release tag. Have I misunderstood something with the implementation here?

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

Example job triggering a release on pull request: https://github.com/mikael-andersson91/try-tag-actions/actions/runs/3396811156/jobs/5648291822

And in-case viewing the workflow run isn't available for you, here's the log from a pull request run where a release tag was created: image

mikael-andersson91 avatar Nov 05 '22 07:11 mikael-andersson91

https://github.com/mathieudutour/github-tag-action/blob/dbd80d2e9d640266d8fe579d11ab9896ed618e16/src/utils.ts#L52-L54

My understanding of this function is that it is supposed to check for pull request events. This would only check for pulls though?

Edit: Nevermind, might have misunderstood that as well. https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally

mikael-andersson91 avatar Nov 09 '22 04:11 mikael-andersson91

@mikael-andersson91 so did you manage to generate prerelease tags? I struggle with branches like feature/*

orkenstein avatar May 01 '23 13:05 orkenstein

@mathieudutour Mathie, thanks you very much for this wonderful aciton! What should we do to avoid tag creation on PR?

orkenstein avatar May 16 '23 14:05 orkenstein

Just don't run the action on PRs?

mathieudutour avatar May 16 '23 15:05 mathieudutour

If that is your solution the README of the repository is misleading on the functionality of the action. I can accept it not being intended to be used for that functionality, but then it shouldn't say this in the README regarding the release_branches argument: 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).

Edit: Running the action on a PR would in most cases mean one does not run it on the master,main branches. At least not when working according to GitHub Flow and having branch protection on those branches

Edit 2: As noted in the issue, when running the action on pull requests tags are created with the next release tag, not a version tag with the commit hash postfix as noted in the README

mikael-andersson91 avatar May 16 '23 15:05 mikael-andersson91

Just don't run the action on PRs?

This is definitely an option, but requires a bit more struggle. It would be awesome not to tag on PR as mentioned in README

orkenstein avatar May 18 '23 07:05 orkenstein