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 mer
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.
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.
Which is all as I would have expected.