Repository navigation
Issue when running within tag push runners. #131
Description
I have the following at the top of my workflow file:
name: useaestrium/tag
on:
push:
tags:
- '*.*.*'
- '[0-9]+.[0-9]+.[0-9]+'
- '[0-9]+.[0-9]+.[0-9]+rc[0-9]+'
# Allows you to run this workflow manually from the Actions tab
workflow_dispatch:
And the running is triggered for a tagged runner.
However, I am seeing the following issue when attempting to push:
fatal: You are not currently on a branch.
To push the history leading to the current (detached HEAD)
state now, use
git push origin HEAD:<name-of-remote-branch>
I'm using the action as follows:
# Push the updated package.json file to the repository
- name: Push package.json version
if: steps.check-tag.outputs.match == 'true'
uses: ad-m/github-push-action@master
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
force_with_lease: true
Is there anything I am doing wrong here, or any way to fix the issue I am seeing?
Activity
ZPascal commentedon Jun 26, 2022
Hi @michealroberts, I'm the person who implemented the force_with_lease functionality. Could you please check and post the checkout section?
It's necessary that you set the following parameters.
michealroberts commentedon Jun 26, 2022
Hi Pascal,
Thank you for your swift response, especially on a Sunday! Thank you.
Hmmm, ok I have that set as you explained and as outlined in the README.md. I wonder if it's because we aren't pushing to origin?
I think it could be because the action is triggered on tag push, and not a branch push?
ZPascal commentedon Jun 26, 2022
Hi Michael, that could be the problem. Do you have a public available Action file that I could copy and paste in my test scenario and checking the case?
[-]Issue when running within on tag push runners.[/-][+]Issue when running within tag push runners.[/+]michealroberts commentedon Jun 27, 2022
I don't I'm afraid - I think the key lies in testing your action within a tagged runner, e.g., something like this:
Let me know if you need anything else ...
ZPascal commentedon Jun 27, 2022
Hi @michealroberts, I've reproduced the issue on my side. I've understood that the job is triggered by a tag. Could you please describe what you want to do exactly and the case? Do you want to push tags or to a branch?
michealroberts commentedon Jun 27, 2022
@ZPascal Hi Pascal. That's great. So when we release, we automatically tag and that then bumps of package.json version to the same tag as the tagged release, and pushes back to the repo. This then triggers a further workflow that essentially runs on any push to main but completes if the version has been bumped in the package.json, at which point it publishes the release.
Hopefully that makes sense!
ZPascal commentedon Jun 27, 2022
Hi @michealroberts, only for better understanding, you push the same tag in the same or in a different repository back?
Update: I think, I've identified the root cause of the issue, and I'm currently working on a solution.
ZPascal commentedon Jun 30, 2022
Hi @michealroberts,
I did some tests with
--force-with-leaseparameter in my test scenario and found that from my point of view, it is not possible to use--force-with-leaseparameter to overwrite a tag. I did a test here with the--forceparameter and was able to successfully overwrite the checked out tag. For this, I also updated the upstream branch at the same time. Is there any obstacle from your side?BTW: Here is the draft PR, which also adjusts the documentation and the push process at the same time.
michealroberts commentedon Jun 30, 2022
Hi Pascal, there may be some confusion. Basically, when the tag changes, I want to be able to push back to the repo. The way I have achieved this outside of this action is the following:
ZPascal commentedon Oct 17, 2022
Hi @michealroberts, so you don't want to update the tagged version and only push pack to the corresponding branch and this is not possible? Is it possible to share the anonymized GitHub Action file to reproduce your case on my test setup?
ZPascal commentedon May 23, 2026
Hi @michealroberts,
After investigating this further, what you're seeing is a workflow design issue rather than a bug in the action. When a tag push triggers a workflow, GitHub checks out the tagged commit directly — no branch, just a detached HEAD. That's why git refuses to push: it simply doesn't know where to push to.
The cleaner approach for what you're trying to do would be to bump package.json before tagging:
Bumping after the tag means the tag itself points to the old version, with the fix sneaking in through a later commit. That defeats the purpose of the tag.
If you still need to push back to a branch from a tag-triggered workflow, you can work around it by explicitly setting branch: main in the action config — that way it pushes
HEAD:main/ masterand git knows the target. I've also added a warning to the action output that flags detachedHEADsituations and points to this recommendation.