GitHub Actions: how to build a pull request as if it were merged?

Question

I'm very excited about GitHub Actions.

I use Travis-CI and AppVeyor now, which have "PR" (pull request) builds that build the code as if the pull request were merged.

I would like to use GitHub Actions for continuous integration, but it seems GitHub Actions only supports building pushed commits, not the result of the merge. How do I achieve the effect I want?

Answer 1

According to https://github.com/actions/checkout/issues/15#issuecomment-524093065 and https://github.com/actions/checkout/issues/15#issuecomment-524107344, if you set your workflow to trigger on the pull_request event rather than the push event, the GITHUB_SHA will be the merge commit, so the checkout action will check out the result of the merge, which you can then build and run unit tests on.

It's also officially documented here:

GITHUB_SHA = Last merge commit on the GITHUB_REF branch
GITHUB_REF = PR merge branch refs/pull/:prNumber/merge

Disclaimer: I haven't gotten into the beta yet, so I can't verify this information for myself; I can just pass on what others have said worked for them.

I've gotten into the beta now, so I can confirm that this works. I ran a build of the following workflow in my test repo:

name: Build PR

on: [pull_request]

jobs:
  build:

    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest, macOS-latest]
        dotnet: [2.2.402, 3.0.100-rc1-014190]
    runs-on: ${{ matrix.os }}
    
    steps:
    # ... trimmed ...
    - name: Dump GitHub context
      env:
        GITHUB_CONTEXT: ${{ toJson(github) }}
      run: echo "$GITHUB_CONTEXT"
      if: runner.os != 'Windows'
    # ... trimmed ...

Here's a build log of that workflow running. The PR is here; the first commit on that PR is commit ID ec81c6f:

When I ran git fetch origin pull/10/merge:merge-pr-10 to fetch the merge commit, the commit I got was f1ea865, a merge of ec81c6f onto 44a09bc (which was the latest commit on my master branch at the time that PR was created). And notice the SHA that was actually built:

So just by using on: [pull_request] as the triggering event of my workflow, it did what I wanted. If you look at the PR's history, you'll see that I tried several things to see what triggered a new build: adding a comment, closing the repo, opening the repo... Here's what I found.

• Adding a comment did NOT trigger a new workflow run
• Pushing a new commit DID trigger a new workflow run
• Closing the PR did NOT trigger a new workflow run
• Reopening the PR DID trigger a new workflow run
• Adding a label to the PR did NOT trigger a new workflow run
• Removing a label from the PR did NOT trigger a new workflow run

Which is all as I would have expected.