Should I run CI on merge state or HEAD of branch in a PR?

Question

I'm using Jenkins Pipeline with Github for our CI purposes and I'm trying to think what the strategy should be for what is checked out to run.

Jenkins provides three options when discovering pull requests:

 1. Merging the pull request with the current target branch revision
 2. The current pull request revision
 3. Both the current pull request revision and the pull request merged with the current target branch.

I'm looking for opinions on what others choose. To run just the branch head because then it's clear exactly what is being run, or to run the merge state because then it makes you more confident when you merge.

Currently, I'm using just the PR branch HEAD and enabled Github to require a master merge if the branch is out of date.

Answer 1

Usually you want to test your code as closely as possible to how it's going to be deployed. This means you're going to want to run your tests against code that's been merged with master, so choose the first option (merge first, then test). There's no point in the 2nd option if you're never going to deploy the code in that state (i.e. unmerged).

Or for another perspective: good CI practices involve merging soon and merging often. This would naturally lead one to the first option.