Don't run Travis builds on master

[aneeshusa]

All commits on master are fast-forwards to merge commits that are
created by homu and already tested by Travis, so testing commits on
master duplicates the build.

[larsbergstrom]

@bors-servo r+

[bors-servo]

📌 Commit 9cbbbf0 has been approved by larsbergstrom

[bors-servo]

⌛ Testing commit 9cbbbf0 with merge 3d1ff41...

[aneeshusa]

If you look at https://travis-ci.org/servo/saltfs/builds, Travis also seems to run the build on the 'auto' branch twice - i.e., for a PR, it'll run the build on auto (for homu), and then after merging run it on master (which this gets rid of) and again on auto. Do you know why this happens? I'd like to remove the other duplicated build as well, but I don't want to break homu.

[bors-servo]

☀️ Test successful - travis

[larsbergstrom]

I think that @Manishearth has also been looking at some of the extra builds on auto. IIRC, it had to do with the double-push that homu does (first a force-push to make auto=master, then a push of the additional commit), as otherwise the single-force push will trigger travis but not buildbot.

However, my memory may be off...

[metajack]

r-

This was tried before and does not do what you want. Here's my email to travis support and their response from July of 2015:

Servo's repos run an auto-lander bot which waits for review
notification and then merges the PR into master on the branch 'auto'
and then if CI passes will fast forward master to auto.

This workflow causes at a minimum these builds:
1) Build of original PR commit (that travis merges)
2) Build of auto
3) Build of master when final merge happens

In order to reduce the spurious build #3 we have added:

branches:
except:
- master

to our .travis.yml files. Unfortunately this seems to have the
unintended consequence of disabling build #1 above.

Is this behavior intended?

Build #2 I assume isn't redundant in some cases, since master may have
move forward after Travis CI has passed a PR. Maybe our auto-lander,
homu (https://github.com/barosl/homu), can detect the case where
master is still the same and avoid build #2 in most cases.

Thank you for the e-mail and sorry for the issue. Unfortunately this is a general problem with a way whitelisting works - it works for both PRs and branches. We're planning to change it, although no work has been done on this front yet. I'll pass it to the team to discuss further and find a good solution.

Unfortunately we don't have any workaround for this at the moment, sorry.

So unless you have information that this behavior is now fixed, please revert this.

[Manishearth]

We could make it so that when it's not a pull request and the branch is master, the travis script is a no-op (there are environment variables).

Alternatively, turn on homu's exemption feature, which lets us skip build #2 if build #1 has the correct HEAD^1sha (only for repos with a single travis builder -- it works by not doing the auto merge in the first place, so if there are multiple builders it can't be done)

[aneeshusa]

:( I didn't realize this had already been tried and doesn't work.

[metajack]

No worries. Great minds must think alike :)