Fail the Travis check as soon as one of the jobs fails

[oprypin]

Fast-Finish Builds with Allowed Failures

I just noticed in this build - the Mac jobs were done in 5 minutes so it was already clear that the check does not pass, but the status on GitHub still showed that the build was in progress until the other, delayed, jobs were done.
So... this fixes that

[RX14]

Just to be clear, the whole matrix keeps running to completion even if one fails?

[oprypin]

Yes.

This actually has clearer info: Fast Finishing

[oprypin]

Uh nevermind, that information is not clearer, because we are not dealing with the "allowed failures" feature at all.

[bcardiff]

@oprypin, travis-ci/travis-ci#2062 (comment) states that outstanding jobs will be probably cancelled in the near future. Unless that turns configurable, I don't think we should include this PR. Knowing which jobs failed could help to know if the problem is scoped to platform.

Today's benefit would be to abort the mac jobs, but upon some failure of the linux 32bits and a later auto cancellation of linux 64bits, the PR owner might need us to trigger manually the cancelled jobs and check if the problem has 32bits only or not.

Please, correct me if I am missing something.

[oprypin]

@bcardiff, has Travis ever broken backwards compatibility on its config? Why would they do that now in the most trivial case where the most obvious solution would be adding another option?

Right now all this does is change the status on GitHub in a smarter way, jobs are never cancelled. And I can't imagine a situation where Travis would suddenly start cancelling jobs for no reason.

Even if such an event with 0.01% probability happens, this configuration can be changed back. So this seems like a ridiculous reason to avoid this option.

[bcardiff]

Ok, it's a good point.