README instructs users to do strange things to their repositories.
The example use of create-release in the README contains this line:
tag_name: ${{ github.ref }}
Should a user leave this in while having actions set to trigger for their master/main branch, this will result in a new tag being created called refs/heads/main... This means:
-
The tag will be the same every time the action tries to create a release
-
After this action is triggered, trying to simply push to the repository (e.g.
git pushorgit push origin master) will not work. Users will probably try to delete the tag... Examples for "delete a tag" found across the internet look likegit push origin :refs/tags/main. The proper way to delete this tag isgit push origin :refs/tags/refs/heads/main, but users will probably mistakenly run other commands such asgit push --delete origin :refs/heads/maindue to the confusing name of this tag, deleting their remote main branch.
I suggest changing the tag_name line in the README's example use to something along the lines of tag_name: release-${{ github.sha }} to ensure the example works out-of-the-box without any unusual issues.
Another tag name that worked for me is tag_name: ${{ github.run_number }}, which I found friendlier than the sha:
run_number: stringA unique number for each run of a particular workflow in a repository. This number begins at 1 for the workflow's first run, and increments with each new run. This number does not change if you re-run the workflow run.
Came here just for this, I messed up my master branch in my repository because I was trying to test the example. At least some comments stating why you shouldn't do it with a non-tagged branch could have helped me avoid this situation.
There was probably an implicit assumption by whoever wrote the README that people would be using this conditionally with version tags so I think there were assuming the step/job would have if: startsWith(github.ref, 'refs/tags/v') which is probably what anyone using some release action like this should have.
@ash0x0 for best practice use I would agree but in some simple projects (such as the one that prompted me to make this issue) it can be useful to just build any commit and create an artifact for it.