• Andrei Alexandrescu (12/12) Sep 04 2016 I'm getting emails about Travis CI builds failing, even for changes that...
• David Nadlinger (9/11) Sep 04 2016 In this case, it's seems to be a race condition between Travis
• David Nadlinger (15/18) Sep 04 2016 Oh, wait, this is on a branch in the main dlang repo, as created
• Andrei Alexandrescu (5/21) Sep 05 2016 FWIW the problem is not limited to branches created in the online

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

I'm getting emails about Travis CI builds failing, even for changes that 
clearly cause no breakage (e.g. 
https://travis-ci.org/dlang/dmd/builds/157445381).

After a few of those, what I feared will happen has happened: I 
effectively treat all similar messages as noise I just delete from 
Inbox. This reflects our experience at Facebook Engineering, where 
spurious failures invariably led to apathy in minding the legit one. I 
recall there's been an explicit effort to weed all spurious failure out.

Can we do the same? How can we make sure that a Travis failure always is 
legit and needs action?


Thanks,

Andrei

David Nadlinger <code klickverbot.at> writes:

On Sunday, 4 September 2016 at 14:46:56 UTC, Andrei Alexandrescu 
wrote:
 Can we do the same? How can we make sure that a Travis failure 
 always is legit and needs action?

In this case, it's seems to be a race condition between Travis 
trying to check out the branch to test, and GitHub actually 
serving it up (or you removing it again).

There is not much we can do about this particular one, except for 
taking it up with the Travis support. And, of course, disabling 
mail notifications for things like that.

  — David

David Nadlinger <code klickverbot.at> writes:

On Sunday, 4 September 2016 at 17:37:28 UTC, David Nadlinger 
wrote:
 In this case, it's seems to be a race condition between Travis 
 trying to check out the branch to test, and GitHub actually 
 serving it up (or you removing it again).

Oh, wait, this is on a branch in the main dlang repo, as created 
by the GitHub online editor. We might want to restrict CI runs to 
the main branches by adding something like this to .travis.yml:

---
branches:
   only:
   - master
   - stable
---

Then again, people shouldn't be creating branches on the main 
repo anyway (although last time I checked, this was 
unavoidable when using the "revert" button).

  — David

Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:

On 9/4/16 7:43 PM, David Nadlinger wrote:
 On Sunday, 4 September 2016 at 17:37:28 UTC, David Nadlinger wrote:
 In this case, it's seems to be a race condition between Travis trying
 to check out the branch to test, and GitHub actually serving it up (or
 you removing it again).

 Oh, wait, this is on a branch in the main dlang repo, as created by the
 GitHub online editor. We might want to restrict CI runs to the main
 branches by adding something like this to .travis.yml:

 ---
 branches:
   only:
   - master
   - stable
 ---

 Then again, people shouldn't be creating branches on the main repo
 anyway (although last time I checked, this was unavoidable when using
 the "revert" button).

FWIW the problem is not limited to branches created in the online 
editor, see e.g. 
https://circleci.com/gh/dlang/dmd/649?utm_campaign=build-failed&utm_medium=email&utm
source=notification 
-- Andrei