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
