Restrict CI to only building the master branch

[DRMacIver]

This is a bit of a speculative PR and I'd like to discuss it before merge.

Travis has an annoying behaviour for pull requests where it builds each pull request twice: Once for the branch, once for the merge commit.

Given Hypothesis's painfully slow builds this is rather frustrating.

As per the Travis documentation we can turn this off and only have it build master. This should still build pull requests, or at least it was the suggested fix for travis-ci/travis-ci#1147.

Do you think this is a good idea? It solves quite an annoying problem but I don't know how annoying not having the CI builds for our branches when we're working on them will be. It would be nice to be able to trigger Travis to run a particular commit manually but I don't think we can.

Update: This now should also do the same thing for appveyor (as per documentation)

[DRMacIver]

@palfrey pointed out on Twitter that a way to force a branch to build is just to create a WIP PR for it, which seems a pretty reasonable solution to me.

[alexwlchan]

tl;dr: I am 👍 this change.

Do you think this is a good idea?

Yes. Faster builds on PRs = better.

It solves quite an annoying problem but I don't know how annoying not having the CI builds for our branches when we're working on them will be.

I think the slowness of PR builds is more annoying than the hypothetical problem of not having CI against branches – particularly because I lean towards having WIP pull requests for branches that are anywhere near mergeable.

A lot of branches with WIP code are only tested manually/locally – I’d guess that CI against those branches would often fail, but not with particularly useful errors.

And if we do have a long-lived branch that we want builds on, but for some reason don’t want a PR, we can always put it back in.

It would be nice to be able to trigger Travis to run a particular commit manually but I don't think we can.

Agreed.

[alexwlchan]

(Related: #444)