How to configure Travis-CI to build pull requests & merges to master w/o redundancy

Question

To put it in "BDD" terms:

Background:
Given I'm contributing to a GH repo

When I create a pull request
Then Travis should build the latest commit

When I push to an existing pull request
Then Travis should build the latest commit

When I merge a pull request to master
Then Travis should build master

I was confused by Travis-CI's "build pushes" and "build PRs" settings, as:

• Enabling both causes each Pull Request to be build twice by Travis
  • once for the commit on that branch
  • and once again for the merge commit of that branch into its destination
• Enabling just "build PRs" causes PRs to be built, but doesn't result in post-merge builds (i.e. on master).
• Enabling "pushes" brute-force satisfies the above criteria by building all pushes to the repo. You can try to finagle things by white- & black-listing branches, but that will probably bite you unless you're rigorously disciplined with branch names.

This is explained more in Travis-CI docs and GH issue #3241.

Anyone know a configuration that satisfies the above criteria?

Answer 1

I eventually found another GH issue (#2111) which gave me the idea to try enabling both PRs & pushes, but with a whitelist to restrict pushes to a specific branch. This seems to satisfy the criteria for my workflow. Here's what I did:

1. Enable both PRs & branch pushes in the Travis settings for the repo:

2. Change .travis.yml to white-list master branch (i.e. only build pushes to master):

 branches:   only:      - master 

3. Test it by creating a PR with the .travis.yml change, and another PR with some empty commits to verify it works for forks too.

4. Verify successful merge commit build from master.

Answer 2

Just found in travis docs

Add to .travis.yml

if: type = push 

alternatively:

if: type = pull_request