Closed justinmchase closed 2 years ago
Thanks for reporting. From your shared output I can see that the Action seems to break when creating the tag in the "local" repo on GitHub Actions; not when pushing to GitHub.
I'm reluctant to add yet another "git-command_options" to the Action. Could you try and delete the tag in the local repo in your workflow file?
name: Publish
on:
release:
types: [published]
jobs:
version:
runs-on: ubuntu-latest
permissions:
contents: write
steps:
- uses: actions/checkout@master
- uses: justinmchase/version@master
with:
action: set
value: ${{ github.event.release.tag_name }}
+ - run: git tag -d ${{ github.event.release.tag_name }}
- uses: stefanzweifel/git-auto-commit-action@v4
with:
commit_message: "${{ github.event.release.tag_name }}"
tagging_message: "${{ github.event.release.tag_name }}"
branch: master
push_options: '--force '
git tag -d
will delete the existing tag in the local repository and should allow git-auto-commit to re-create the tag in the next step. --force
in push_options
might then not even be necessary.
I thought it was going to work for sure but it seems like it has an error on the push step still?
Interesting. If I read justinmchase/version correctly, this Action just creates the tag locally and does not push it to GitHub.
A thing that springs to my eye is "Switched to a new branch 'master'".
You're listening to the release
-trigger and let actions/checkout check out the repo to the tag that has been created by the GitHub release.
So the tag already exists on the remote git repository on GitHub.
To delete the remote git tag you would have to run
git push --delete origin ${{ github.event.release.tag_name }}
But the GitHub release is tied to that tag and sha. Not sure what happens if you delete the tag.
If I understood your intentions correctly, you
VERSION
file and write the newly created version tag to that fileYou could try to run the above command in addition to git tag -d
and then maybe add --tags
to the push_options
… but it feels a bit icky.
I would suggest updating the VERSION
file, before creating the release.
In the past I had interactions with other users on GitHub on other Actions of mine, which were in a similar position like you are (create release, then want to add a commit to that release). Here are some links to issues and discussions about this:
Yeah I think you understand. It does feel icky. I think that the right answer here is for me to just take another approach, which isn't due to a problem or limitation of this action, just that the approach I was taking is "icky".
The process was:
The problem with that is that tag is pointing to a commit before the files in the repo had their version set. So I was planning on moving the tag after the fact... But it's gross as you noted.
So I think what I'm going to do is to just update the version and commit / push when the Draft Release is produced. Then when the Release is published it already has the version file commits. No need to delete and re-create tags.
I would suggest updating the VERSION file, before creating the release.
☝️ Yup, that was my though as well.
Version of the Action
v4.x.x
Describe the bug I'm trying to overwrite a tag. My code change is to update code in the repo based on the version tag just created, but I want the tag to apply to the new commit so I need to be able to force push the tag, however the push options seem to not apply when pushing tags and there doesn't appear to be a separate field for tag push options.
My workflow step:
Error message thats produced despite the
--force
push option.To Reproduce Steps to reproduce the behavior:
Expected behavior I expect the tag to be force pushed
Screenshots N/A
Used Workflow
Additional context Add any other context about the problem here.