A few things to note

1. this action required a tag because GitHub releases do. That is not a bug.

2. The push event that triggers the workflow run needs to be the push associated with a git push origin {tag}. The reason being that GitHub releases can only be created if GitHub servers know about the associated tag.

It looks like the push that is triggering these runs is a push of a commit.

3. the tag operation within the workflow only exists in the workflow run checkout, not on your GitHub origin remote. If you push this within your workflow run it should trigger another run where the push is for your tag

4. environment variables export within a step are not by default exposed to future steps. This is because every step runs in its own process.

You can use a custom command to pass env variables between workflow steps

I will try and follow up on this with documentation on a strategy for creating tags within a workflow run

I'm also struggled with that problem, trying to fix it somehow.
Is there any hack on how to create tag automatically after creating and publishing release?
Or maybe some option to ignore tag checking (as it worked before)?

I notice same error in https://github.com/diofant/diofant/commit/6740f83761a14a06f44ab0b1d001907f70bcba0e/checks?check_suite_id=262644565
This build was initially triggered by tag push, but was unsuccessful due one of slow tests and then - was restarted.

I'm using gitversion for versioning, which handles versioning based on branches... It doesn't work when checking out a tag instead of a branch so I can't use a github workflow triggered by a pushed tag.

I've currently got the following steps:

    - name: Tag
      if: startsWith(github.ref, 'refs/heads/release/')
      run: |
        git tag "v$env:GitVersion_SemVer"
        git push origin "v$env:GitVersion_SemVer"
    - name: Release
      if: startsWith(github.ref, 'refs/heads/release/')
      uses: softprops/action-gh-release@v1
      with:
        name: v${{ env.GitVersion_SemVer }}
        prerelease: ${{ env.GitVersion_PreReleaseLabel != '' }}
        files: ./artifacts/sidekick-*.zip
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Couldn't action-gh-release create the release based on the name I'm providing? What additional information does it need that requires this be a pushed tag that triggered the build?

+1 to this confusion; see no reason that I can't specify a tag name and this Action tags & releases all in one go.

+1 same here

+1

Is this still an issue? I'm triggering release process based on a pull request merge for branches prefixed with release/. I will want to create a tag AND github release in this workflow.

If @softprops is inactive I may look elsewhere. It's unfortunate because it's hard to find an action that will also allow you to upload artifacts.

Well I added a tag and still got that error :/

git tag 1.1.1
git push origin master 1.1.1

anyone managed to get passed this? example would be appreciated.

I swithed to another action that does it easy.

I swithed to another action that does it easy.

same here

I swithed to another action that does it easy.

@roslovets If you did, please mention the name here to help others out. Thank you.

@roslovets If you did, please mention the name here to help others out. Thank you.

I use ncipollo/release-action to create release just after tagging in the same workflow. Example

In fact, as @softprops said, you need a tag to create a release.

Regarding what @Septias said, it still doesn't work after adding the tag, I think it may be that the tag is not pushed to github, for more discussion on this see: Push git commits & tags simultaneously

This issue is basically related to tag_name, and here are a few ways to solve the problem.

1. Set your action to trigger only when it contains a tag
2. Specify a tag explicitly

The following example specifies a tag named "test":

    - name: Release user files
      uses: softprops/action-gh-release@v1
      with:
        tag_name: test
        files: |
          file1
          file2

Specifying a tag for each commit is annoying. As in the example given by @roslovets, you can use version number control for the tag.

Another example is to specify a tag name for each nightly build version:

    - name: Generate release tag
      id: tag
      run: |
        echo "::set-output name=release_tag::UserBuild_$(date +"%Y.%m.%d_%H-%M")"
    - name: Release user firmware
      uses: softprops/action-gh-release@v1
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      with:
        tag_name: ${{ steps.tag.outputs.release_tag }}
        files: |
          file1
          file2

Ahh, you may be wondering why we don't generate times like 08:11? I would like to remind you that the character : is not legal in the git tag.

Thank you for the clarity and your example approaches, #20 (comment)

Thanks for this amazing example @windowsair .
Also, to point out for someone who will stumble on this issue... that id: tag is important for that section.
I didn't add it and wasted 30 minutes trying to figure out why my tag wasn't working.

I used another action to get the previous tag

      - name: 'Get Previous tag'
        id: previous_tag
        uses: "WyriHaximus/github-action-get-previous-tag@v1"
        with:
          fallback: 1.0.0
      
      - name: Release        
        uses: softprops/action-gh-release@v1
        with:
          tag_name: ${{steps.previous_tag.outputs.tag}}
          files: ${{steps.sign_app.outputs.signedReleaseFile}}

Same issue here despite having tags fetched in a seperate step to checkout. You can also do this by specifying depth: 0 but it also pulls all history.

The check if a tag exists is done against the github ref, Which regardless if a tag is associated/pointing at that commit will refer to the branch name if it's a branch (the Github documentation on this has evolved over the years and not always been accurate!)

Here the ref is checked rather then if a tag is pointing at the commit sha, Which is the way GHA documents it.

"ref": "refs/heads/REDACTED-123",

I'm not sure what is right or wrong here as based on long running discrepancies in GHA documentation and actual behavior.

Most of the advice on the interwebs is to check this ref for a tag type of ref. To use any tagging at all in my workflow I had to do it this way:

      - name: Check if Git tag exists
      id: check_tag
      run: echo "::set-output name=TAG::$(git tag --points-at ${{github.sha}})"

Going to use the mentioned tag_name param, Thanks everyone.

The approach used by all these actions is horrible. All are built around pushing a tag to have a build. It kind of defeats a primary goal of continuous integration - build on every code change. Instead, it's - build on every tag release.

I'm just leaving this comment here with hope it will be helpful as I came up with what I think is an elegant solution.
My initial goal was to create a continuous integration system around my C++ CMake project which will build / test / package and ultimately automatically create a release with packages for my matrix configuration, so far only 32-bit and 64-bit windows.

I believe a lot of folks don't realize that all these actions are built using either REST API or nice little utility from GitHub called hub (which I guess is using REST API too): https://hub.github.com. The good thing about it is that it's automatically available on your runners and it's literally 1-line command to create your release which can automatically create a tag for you and upload your packages.

Instead of using action, you can use something like:

      - name: 'Create Release'
        run: hub release create release_name -m release_message -a your_build_artifact.zip
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

The only thing you have to do to make it work is to add permissions to your GitHub token to be able to create releases, that can be done in your repository options. My full workflow example is slightly more complicated but here it is for the reference:
https://github.com/superg/redumper/blob/main/.github/workflows/cmake.yml

The approach used by all these actions is horrible. All are built around pushing a tag to have a build. It kind of defeats a primary goal of continuous integration - build on every code change. Instead, it's - build on every tag release.

build ≠ release

The approach used by all these actions is horrible. All are built around pushing a tag to have a build. It kind of defeats a primary goal of continuous integration - build on every code change. Instead, it's - build on every tag release.

build ≠ release

Yes, but you want your build deployable one way or another. If you ever used GitHub artifact storage, you're well aware of it's limitation.

The approach used by all these actions is horrible. All are built around pushing a tag to have a build. It kind of defeats a primary goal of continuous integration - build on every code change. Instead, it's - build on every tag release.

build ≠ release

Yes, but having to manually trigger a tag release to do a release is not what I would call continuous automation. Even a manual trigger of your deploy workflow (which you may want to do) will not work, and any other automation that is not creating a tag will not work either.

I solved the problem.

https://github.com/ramazansancar/gnojus_wedl-go/blob/master/.github/workflows/release.yaml

It works flawlessly for this place.

All I did was on the command line, respectively:

git tag v1.0.9
git push origin v1.0.9

# Create Tag
git tag <tag>

# Last commit connection the tag
git push origin <tag>

Before: https://github.com/ramazansancar/gnojus_wedl-go/actions/runs/8681675249

After: https://github.com/ramazansancar/gnojus_wedl-go/actions/runs/8681705139