Run softprops/action-gh-release@v2 Error: ⚠️ GitHub Releases requires a tag

[BaseMax]

      - name: Create tag
        id: create_tag
        run: |
          tag_name="v1.0.${{ github.run_number }}"
          git tag $tag_name
          git push origin $tag_name

      - name: Create GitHub Release
        uses: softprops/action-gh-release@v2
        with:
          files: |
            release/salam-linux
            release/salam-mac
            release/salam-windows.exe
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

[BaseMax]

Fixed by adding a tag_name, but the problem and error is: it shows same error even when I am passing the tag_name.

My mistake was I need to keep "v" at beginning of tag_name.

I think it's better to improve error message of this action.

Thanks again.

[VioletGiraffe]

Thank you for showing how to create a release from a non-tagged commit. Are you required to push the tag? I would prefer to not litter the repo with garbage tags.

[gh-andre]

@VioletGiraffe

Are you required to push the tag? I would prefer to not litter the repo with garbage tags.

It's not really a tag name but rather a "proposed tag name", which will become an actual tag when the draft release is published. Here's how it's supposed to work:

• Create a draft release with build artifacts and the proposed tag of the upcoming release (no tag is created at this point)
• Test artifacts
• If the tests fail, discard the draft release
• Fix the problem
• Run the pipeline again, so it creates another draft release with a new set of artifacts and the same proposed tag
• Test artifacts
• If the tests are successful, then publish the release, at which point the proposed tag becomes the real tag

Many people publish their release right away, without the draft release, which is what creates those garbage tags that need to be deleted if tests fail.

[BaseMax]

I fully handled this process in one of my project by getting help from GitHub action and some other packages. here are full source of my showcase:
https://github.com/SalamLang/Salam/blob/main/.github/workflows/build-release.yml

Short brief: I am automatically release and build my compiler/programming language for 3 different OS (Windows, Linux, macOS) This github action is making this process automaticly, we are getting VERSION number from a file which standed in the root and we create tag and release in the github automaticly by using that VERSION number.

Best,
Max

[gh-andre]

@BaseMax

There's a couple of points you may want to consider with this setup.

The most important one is that build artifacts in this workflow are being released without any testing. So, for the amount of time it takes you to test these artifacts and issue a fix, a buggy version will be tagged and made available through a non-draft release, and perhaps on whatever website that POST request is made to.

You may also want to avoid using latest build images. This will eventually cause compiler compatibility issues when GitHub deploys new build images with new compilers, which may be incompatible with the current source. Typically you'd want to pick a specific GitHub image, like ubuntu-24.04 or windows-2022, so you always know what toolset will be available. When you're ready to move to the next compiler version, only at that time you would pick the new build image in the workflow file.