Detached HEAD State

[peter-evans]

When using this action it leaves the repository in a "detached HEAD" state. Is there a way to checkout the branch that initiated the workflow in an attached, usable state?

The checkout for Actions v1 using the HCL workflows worked differently and didn't leave the repository in a "detached HEAD" state.

[TingluoHuang]

in Actions v1, i think you only get a tar ball of your git repository, you can't run git operations on it.
we checkout commit instead of branch since the branch might get more commits after the workflow get triggered.

[vlymar]

@TingluoHuang, actions v1 definitely checked out the repository to a branch, complete with all git metadata. LaunchDarkly's GH action was built around running git operations on the checked out repo. We are now implementing a workaround for this detached head issue (e.g. reading branch name from GITHUB_REF), but the new actions/checkout was a breaking change for us. I understand the concern about more commits coming after the workflow gets triggered, but it all seemed to work neatly in v1.

@peter-evans, an extremely hacky workaround that could be used short term to get the repo into a non-detached state would be to add this step after the actions/checkout step:

- name: Prepare repository
  run: git checkout "${GITHUB_REF:11}"

I'm not sure what happens if there have been more commits since the workflow was triggered, it depends on how actions/checkout works, but it may very well run against the latest commit instead of the one that triggered the workflow.

[TingluoHuang]

@vlymar can you share some context around how you use the checkout repo in actions v1? are you making a commit and push back to origin?

if we want to make actions v2 has the same behavior as actions v1, I guess we need to checkout the branch and reset HEAD to SHA.
The downside i can think of is we will leave a local ref around after each run finished on the runner.

@chrispat to decide which direction to go. :)

[vlymar]

Our action scans the repository for feature flags and posts the results back to launchdarkly. It's triggered by push events so it runs on any branches under development. We want to be able to show information about feature flag usage per branch so we post the branch name the action is running for.

We were aware of GITHUB_REF for v1, but didn't build around it because our scanner is designed to run in multiple contexts: CLI, github actions, docker run, circleci, bitbucket pipelines, etc. We tried to make it as generic as possible, so we got the branch name by running git rev-parse HEAD. We're currently adding a special case for github actions to read the branch name from the GITHUB_REF.

[peter-evans]

To add some context from my use case. I wrote an experimental action that creates a pull request for any changes to the actions workspace. I realise it's not good practice in general to modify a repository during a workflow, but it opens up some interesting possibilities when used carefully.

I managed to work around the changes that were made between v1 and v2 Actions:

• Extracted the active branch name from GITHUB_REF as @vlymar suggested
• Updated the origin remote URL to add token auth
  git remote set-url origin https://$TOKEN:x-oauth-basic@github.com/username/repository
  Learnt that the following way allows the default GITHUB_TOKEN to be used to commit.
  git remote set-url origin https://x-access-token:$GITHUB_TOKEN@github.com/username/repository
• Used a repo scoped token instead of using the default GITHUB_TOKEN. The GITHUB_TOKEN now seems to have further restricted access compared to v1 and I wasn't able to git push.
  This is incorrect. See the above point.

[vlymar]

Updated the origin remote URL to add token auth
git remote set-url origin https://$TOKEN:x-oauth-basic@github.com/username/repository

This is actually relevant for us too, thanks for posting!

For context, we use ls-remote to prune stale branches from launchdarkly.

[chingc]

I'm also in the same boat and would love to be able to checkout without being put into a detached head state. I currently have to resort to sed, which isn't as terse as the bash substring extraction solution by @vlymar.

- name: Reattach HEAD
  run: git checkout "$(echo ${{ github.ref }} | sed -E 's|refs/[a-zA-Z]+/||')"

A true/false option would be nice and would preserve both behaviors.

[TingluoHuang]

I have a fix that almost ready, will finish testing and release to GitHub Actions.

[elstudio]

Meanwhile, here's an action that works around the current detached head state, using a sh one-liner to parse $GITHUB_REF and checking out the current branch:

https://github.com/elstudio/actions-js-build/tree/v2/commit

It also sets up git to commit with the appropriate username and email address.

[chingc]

Any updates?

[timmehhh7]

We are having the same issue since moving to new Actions and using checkout. Our use case is some python scripts that get executed and generate files, then push them back into the repo on the same branch/PR. I tried using the fixes above and the GH event data isn't consistent so I can't reliably get the Branch name from it. ie sometimes "github.ref": "refs/pull/575/merge" as an example. Which doesn't work. In those cases head_ref is populated, however if the ref is like above, head_ref is empty.

Either way there is no reliable way to get a branch name it seems. Why can't we just have the checkout action clone the current branch?

[peter-evans]

Learnt a different way to set the git remote that allows the default GITHUB_TOKEN to be used to commit. Updated my comment here #6 (comment)

[hashim-sohail]

Is there a workaround?

Running semantic-release in GitHub Actions fails at @semantic-release/git which throws error HEAD:undefined