2

When I create a PR, GitHub CI (via the actions/checkout action) 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 other 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

Is there a way to make GitHub CI build the test merge of a PR, rather than the head of the PR branch?

Adam Ralph
  • 29,453
  • 4
  • 60
  • 67
  • What does the GITHUB_REF environment variable look like? If it's something life `refs/pull/123`, you could try specifying the `ref` input to `checkout` (see https://github.com/actions/checkout/blob/master/action.yml for a complete list of inputs) and make it be something like `$(GITHUB_REF)/merge`. Note that that's Bash syntax, not GitHub action YAML syntax; I'm not in the beta so I can't test this idea myself. – rmunn Aug 19 '19 at 16:36
  • @rmunn thanks for the suggestion. Unfortunately `GITHUB_REF` is set to the PR branch name, e.g. `refs/heads/mybranch`. Looking at https://help.github.com/en/articles/virtual-environments-for-github-actions#default-environment-variables it seems like there is currently nothing which can be used to determine the pull request number. BTW - I raised https://github.com/actions/checkout/issues/15 – Adam Ralph Aug 20 '19 at 11:58
  • @AdamRalph What event are you using to trigger the workflow? i.e. `on:` – Electric Sheep Aug 22 '19 at 15:01

1 Answers1

-1

As per https://github.com/actions/checkout/issues/15:

The GitHub docs are misleading:

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.

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.

Adam Ralph
  • 29,453
  • 4
  • 60
  • 67
  • I'm not sure that's always true... I was able get the checks running multiple times off of a PR by pushing, adding a second commit, pushing that, then resetting the branch back to the first commit and force pushing. – João Bragança Aug 27 '19 at 07:38
  • That's not ideal, but I think it's OK. BTW are you sure that the target branch (e.g. master) didn't move on in the meantime? Since that would mean the test merge would necessarily be different. But I guess this is happening regardless of that, since the force push means a new merge commit is created, and that commit would never have been built yet. – Adam Ralph Aug 28 '19 at 12:00