Checkout: Checkout@v2 detached HEAD

[rachelluli-guetta]

Hi,
I have a workflow that runs on pull requests, what it does is:

1. Checkout
2. Create a commit based on the pull request label and push

Had to do some workarounds to make it work in checkout@v1 so now I switched to checkout@v2 but I still get:

[detached HEAD xxxxxx] ...
...
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>

[ericsciple]

The pull request refs aren't regular branches so detached head is intentional.

V2 fetches depth 1 by default. It sounds like the lack of history might be the issue? Setting fetch-depth: 0 might fix the issue?

[ericsciple]

if so, related to PR #127 (added note about fetch depth to the summary)

[ericsciple]

If you intend to push changes, you'll need to create a branch.

[ericsciple]

Closing. Reopen if still hitting issues.

[bazzadp]

@ericsciple I'm a little confused with this.

So we have a branch with a change on it. What I want to do is complete an action on that branch (let's say I've a repo with some markdown I want to auto generate HTML from when any changes are made to the markdown files).

Now this is very easy to do when completing this action on a push. However that means this Action happens each time the code is pushed to GitHub. This will then require the person working on that branch to pull the changes made by my GitHub /Action on that branch, before they can push another change. This could get tiresome if pushing a lot of commits periodically.

So I thought to only run this action when upon opening a pull request as by that time any changes should hopefully have settled down a bit. But then I ran it this detached head issue, which I'll admit I don't really understand (I'm far from a Git expert!).

So is it not possible to add directly to a branch that is part of a pull request and you must create another branch from that instead?

If that is the case, then what is the recommended workflow for this as would have thought it was a fairly common request.

• Do we create a separate branch and merge it into this one to add the changes to this PR?
• Do we create a separate branch and create a separate PR for this auto generated stuff so now have two PRs?
• Do we only run this on master so it's only actioned after a pull request has been merged, but then we can't see the impact of the changes when reviewing the pull request?

Any advice appreciated as a bit new to this!

[ericsciple]

@bazzadp sorry for the delay, i was out and just catching up on notifications

[ericsciple]

@bazzadp i had a similar problem, but went a different direction.

I added a gendocs command to the package.json. The workflow runs npm run gendocs and then verifies no unstaged changes. Otherwise fails with a message telling user how to fix.

Automatically pushing commits is an alternate approach but tradeoffs I personally didn't want:

• Requires a PAT
• If forks are a scenario for you, then secrets not available during fork PR. So would need to run on master instead of PRs. Rules out separate branch/PR approach as well (for forks).
• I also worry about automated generation accidentally causing a loop :)

[ericsciple]

The detached head issue is because checkout during a PR happens against the merge ref, not a branch. Branches are like refs/heads/some-branch. The merge ref is like refs/pull/8/merge. When git checks out anything that is not a branch, it does detached HEAD (effectively checks out the commit, branch not setup pointing to it)

You could checkout the branch instead. The branch is available from the github context (i assume, havent tried). This snippet can be used to dump the context:

on: push
jobs:
  one:
    runs-on: ubuntu-16.04
    steps:
      - name: Dump GitHub context
        env:
          GITHUB_CONTEXT: ${{ toJson(github) }}
        run: echo "$GITHUB_CONTEXT"

It would be similar to this scenario where the branch HEAD commit is checked out. Looking at the event payload docs it looks like it might be ${{ github.event.pull_request.head.ref }}

Again note, this wont work for forks. 1) because the ref from the fork repo wont exist and 2) because you would need to push to the fork repo

[ericsciple]

@bazzadp hope that helps. Let me know if i can help further.

Folks on the community forum might have better suggestions

[bazzadp]

Thanks for getting back to me.

Again note, this wont work for forks. 1) because the ref from the fork repo wont exist and 2) because you would need to push to the fork repo

Yeah this is where I really want it to work to be honest. We want to be able to accept typo pull requests from people not familiar with the site build process, and then not have the next person to build the site suddenly see changes they did not do included in their PR.

The Calibre Image optimisation app does this very well. When you open a PR with images, it optimised the images and updates the PR with the optimised images. See this comment as an example:

Looking at their source code it appears they use the GitHub API and create a new tree and then replace the PR with that tree, so doesn't look simple. But does work very well, so would be really useful to be able to do with this Checkout action. However if that's not possible, or overly complex so something you don't want to add, then I can understand this and feel free to close this issue.

[ericsciple]

@bazzadp cool i didnt realize the built-in token has push permission.

It looks like Calibre is pushing to the user's branch. I would expect their solution to have the drawback you mentioned: "require the person working on that branch to pull the changes".

Additionally, the Calibre solution will not work for forks. The built-in token does not have permission to push to the fork repo where the user's branch is located.

Therefore I would suggest a workflow that runs only against master. Something like this:

on:
  push:
    branches:
      - master
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - run: |
          if [ ! -e gen.txt ]; then
            echo hello > gen.txt
            git config user.email "[email protected]"
            git config user.name "github-actions"
            git add gen.txt
            git commit -m "generated"
            git push
          fi

[bazzadp]

It looks like Calibre is pushing to the user's branch. I would expect their solution to have the drawback you mentioned: "require the person working on that branch to pull the changes".

Yes it does. However, by only doing this when opening a pull request, the annoyance factor is much less than doing it on every push.

Additionally, the Calibre solution will not work for forks. The built-in token does not have permission to push to the fork repo where the user's branch is located.

It does work for forks!

In this case I think the action is initiated by the fork updating it's own repo, not the upstream repo trying to update the forked repo. Of course this only works once the action is cloned down to the fork, but with actions only requiring a simple file in the .github/workflows, and using the built in GITHUB_TOKEN that is set up automatically for you, this basically happens by default with no effort from the forker to setup (other than cloning after we add this action to upstream, or rebasing to pick it up if cloned before this was added).

And it also works for fine non-forked branches as well.

Therefore I would suggest a workflow that runs only against master.

Yup that's what I've ended up doing for now. It works, but it does make some people nervous that we are committing changes directly to master without reviewing them as part of a PR. If the generate script messes up then master could get in a bad way. Hence why I was looking for a better solution to add to PR instead.

[elyalvarado]

@bazzadp I got it working with @ericsciple suggestion (passing the ref to the actual PR branch head). This allowed me to do push after my action automatically generates the changes I needed:

    steps:
    - uses: actions/checkout@v2
      with:
        ref: ${{ github.event.pull_request.head.ref }}

Just letting this here for anybody that hits the same issue. However, please note that I didn't test this on forks, however if the action runs on the fork as @bazzadp mentions it might work.

[chingc]

I just experienced this issue myself. Thank to the suggestions in this thread I was able to fix the issue. FYI, my workflow triggers on pull_request and on push, so here's what my config looks like in case someone does something similar.

steps:
- uses: actions/checkout@v2
  if: github.event_name == 'pull_request'
  with:
    fetch-depth: 0
    ref: ${{ github.event.pull_request.head.ref }}

- uses: actions/checkout@v2
  if: github.event_name == 'push'
  with:
    fetch-depth: 0

[bazzadp]

Additionally, the Calibre solution will not work for forks. The built-in token does not have permission to push to the fork repo where the user's branch is located.

It does work for forks!

Upon further investigation it does not work for forks - it just fails silently so I presumed it was working when it wasn’t 😔

So you can do it on pull requests within the current repo (by passing the ref) but not for pull requests from forks.

Therefore it does look like the best option, to also support forks, is to just use Actions for checks, and then open another pull request for changes upon merge, instead of trying to add to the current pull request. That’s quite easy with this Action: https://github.com/peter-evans/create-pull-request and also has the benefit of allowing you to review any changes. The down side is the extra PR and need to be careful to avoid an infinite loop as that merging PR may kick off this whole workflow again!