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

Brian Gerstle picture Brian Gerstle · Aug 7, 2015 · Viewed 23.8k times · Source

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

Brian Gerstle picture Brian Gerstle · Aug 7, 2015

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:

travis push/pr settings enabled

  1. Change .travis.yml to white-list master branch (i.e. only build pushes to master):
branches:
  only: 
    - master
  1. 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.

  2. Verify successful merge commit build from master.

build result of merge to master