Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 1 commit into from May 5, 2017

Conversation

oprypin
Copy link
Member

@oprypin oprypin commented Apr 29, 2017

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
Copy link
Contributor

RX14 commented Apr 29, 2017

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

@oprypin
Copy link
Member Author

oprypin commented Apr 29, 2017

Yes.

This actually has clearer info: Fast Finishing

@oprypin
Copy link
Member Author

oprypin commented Apr 29, 2017

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

@bcardiff
Copy link
Member

bcardiff commented May 4, 2017

@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
Copy link
Member Author

oprypin commented May 4, 2017

@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
Copy link
Member

bcardiff commented May 5, 2017

Ok, it's a good point.

@bcardiff bcardiff merged commit a859fa9 into crystal-lang:master May 5, 2017
@bcardiff bcardiff added this to the Next milestone May 5, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants