Willy,

Am 24.07.19 um 05:55 schrieb Willy Tarreau:
> I also noticed the build failure but couldn't find any link to the build
> history to figure when it started to fail. How did you figure that the
> commit above was the first one ?

While I did it as Ilya did by scrolling through GitHub's commit list,
there is also:

Travis: https://travis-ci.com/haproxy/haproxy/builds
Cirrus: https://cirrus-ci.com/github/haproxy/haproxy

Keep in mind for both that only the current head after a push is being
built, so larger pushes might hide issues to CI. In this specific case
the offending patch was pushed together with 7764a57d3292b6b4f1e488b
("BUG/MEDIUM: threads: cpu-map designating a single") and only the
latter was tested.

>> This one fails because there's a L4 timeout, I can probably update the regex 
>> to
>> take that into account, the interesting part is the failure and the step at
>> which it fails, but for now we expect a connection failure and not a timeout.
> 
> There's always the possibility (especially in CI environments) that some
> rules are in place on the system to prevent connections to unexpected ports.
> 
> Ideally we'd need a level of failure in CI builds. Some should be just of
> level "info" and not cause a build error because we'd know they are likely
> to fail but are still interested in the logs. But I don't think we can do
> this.
> 

I'm not sure this is possible either, but I also don't think it's a good
idea, because then you get used to this kind of issue and ignore it. For
example this one would probably have been written off as "ah, it's just
flaky" instead of actually investigating what's wrong:
https://github.com/haproxy/haproxy/issues/118

Best regards
Tim Düsterhus

Reply via email to