Checkout the test merge of a PR, rather than the head of the PR branch

[adamralph]

When I create a PR, actions/checkout checks out the head of the PR branch. For example, if the head of the PR branch has the SHA cc87b2733dfbe579a4451b2359191a6c512207c3, I see this in the GitHub CI log:

git checkout --progress --force cc87b2733dfbe579a4451b2359191a6c512207c3

Whereas most CI systems check out the test merge of the PR. For example, if the PR number is 123, in the Travis CI log I see:

git fetch origin +refs/pull/123/merge
git checkout -qf FETCH_HEAD

And in the Appveyor log I see:

git fetch -q origin +refs/pull/123/merge
git checkout -qf FETCH_HEAD

actions/checkout should check out the test merge of a PR, rather than the head of the PR branch. Or it should at least have an option to do that.

[adamralph]

FYI I've also sent a support request (ticket # 353792) to GitHub asking for an environment variable to be added which gives us the PR number.

[ibrasho]

You can get the PR number by doing this for now:
PR_NUMBER=$(jq .number < $GITHUB_EVENT_PATH)

[hashtagchris]

If your workflow triggers on the pull_request event, GITHUB_SHA will be set to the merge commit, and actions/checkout will check out the merge of the PR.

[Ignigena]

If your workflow triggers on the pull_request event, GITHUB_SHA will be set to the merge commit, and actions/checkout will check out the merge of the PR.

I was able to confirm that it's just this easy. Adding the pull_request trigger to my workflow I now have two builds that run with the PR trigger correctly checking out the merge of the PR:

git -c http.extraheader="AUTHORIZATION: basic ***" fetch --tags --prune --progress --no-recurse-submodules origin +refs/heads/*:refs/remotes/origin/* +refs/pull/9/merge:refs/remotes/pull/9/merge

Maybe it was the docs that threw me off initially. It looked like the pull_request trigger only fired when the PR was opened, labels changed, etc. In particular this line in the docs sent me down the path of trying to get things to work on push only:

If you intend to use the pull_request event to trigger CI tests, we recommend that you set up your workflow configuration to listen to the push event.

Worth calling out for others that may have missed this like me: one of the events that triggers pull_request is the synchronize action which according to other docs is "Any time a Pull Request is updated due to a new push in the branch that the pull request is tracking"

[adamralph]

Thanks everyone for input here. I believe it was the docs that led me down the wrong path, as @Ignigena demonstrates. I've discovered that the following works exactly as I want:

on:
  push:
  - master
  - release-*
  pull_request:

I was concerned that I would get too many builds triggered using the pull_request event, since according to the docs:

Triggered when a pull request is assigned, unassigned, labeled, unlabeled, opened, edited, closed, reopened, synchronize, ready_for_review, locked, unlocked or when a pull request review is requested or removed.

But it seems that GH actions is clever enough not to trigger a rebuild of a commit that was already built.

[AlCalzone]

Adding the pull_request trigger to my workflow I now have two builds that run with the PR trigger correctly checking out the merge of the PR:

@Ignigena Can you point me to an action where you do that? I currently have my tests run on push and pull_request events which is pretty pointless if they both test against the unmerged branch.

[adamralph]

@AlCalzone if you are using the pull_request event then your workflow will run against the test merge.

[AlCalzone]

@adamralph ok thanks. I guess I misunderstood Ignigena's comment then.

[hashtagchris]

Hi @Ignigena 👋, the pull_request docs have been updated by our docs team. Hopefully the behavior is clearer now. 😄

[mathstuf]

What if I don't want to run it on a merge with the target branch and instead run it on the PR as it exists on the topic (e.g., run even if it has merge conflicts)? Is there some setting available to do that?

[adamralph]

@mathstuf I believe, in that case, you should be using the push event instead of the pull_request event, ensuring that you are not filtering out the branch name.

[mathstuf]

I now see that this is actually a different issue.

[mathstuf]

Sorry, just saw you reply. This action I'm writing should only run on PRs though (it submits check statuses based on PR metadata and the branch itself as it exists).

[mathstuf]

Since this is larger than this repo, I filed an issue on the community page.

[artem-zinnatullin]

I've read through the thread, we have the configuration according to the comments and docs:

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

(same YAML across all opened PRs and main branch)

yet I do not see GitHub Actions rebuilding PRs when other PR gets merged into main.

Expected behavior

When main (or other target branch) is updated, PRs opened against this branch should be rebuilt. Thus verifying that code changes in the PR are logically compatible (compilation, tests) with new version of main branch and are safe to merge.

Observed behavior

When main branch is updated, PRs opened against main are not rebuilt. They stay with old CI builds staled for hours, days. Thus merging them is not safe.

[adamralph]

@artem-zinnatullin I would open a new issue for that. This issue is for something else.

[jakirkham]

If your workflow triggers on the pull_request event, GITHUB_SHA will be set to the merge commit, and actions/checkout will check out the merge of the PR.

Took me a while to find this, but this is mentioned in the docs.

[natebosch]

When does the refs/remotes/pull/<id>/merge reference get updated? If I rerun an action in a PR after merging to the main branch I don't see those new commits reflected in the test. The SHA for /merge that gets merged into in actions/checkout output is stale.

[jakirkham]

Right one would need to update the PR branch (perhaps using this feature). This would be needed anyways to rerun CI. Alternatively one could close and reopen the PR, which would also trigger this update (and CI rerun)