One strategy I use for our flaky bots is to have them email me only. If the
failure is real, then I forward the email to who ever I find on the blame list.
For a flaky build, this is least you can do. For our flaky builds I know how and
why they are flaky, some person that gets email does not. This is also a great
motivator to help me know what is wrong, and how to fix it. By default, all new
builds I create I do this, until I decide the SNR is appropriate for the
community. Yes I have to triage builds sometimes, but I have an interest in
them working, and people always acting on green dragon emails, so I think it is
worth it. Beyond that, we have regexes which identify common failures, and
highlight them in the build page and log. For instance, a build that fails with
a ninja error, will say so, same with a svn failure or a Jenkins exception.
We also have a few polices on email: only email on first failure, don’t email on
exception and abort, and don’t email long blame lists (more than 10 people).
These require some manual intervention sometimes. But no point in emailing the
wrong people, or too many people. We also track the failure span for all of our
builds, if any fail for more than a day, I get an email to go shake things up.
We also keep a cluster wide health metric, which is the total number of hours of
currently failing builds, I use this as an overall indicator of how the builds
are doing.
In all our CI cluster we use phased builds. Phase 1 is a fast incremental
builder and a no bootstrap release asserts build. If those build, we trigger a
release with LTO build, if that works, we trigger all the rest of our compilers
and tests. It is a waste to queue long builds on revisions that have not been
vetted in some way. In some places the tree of builds is 4 deep, and the turn
around time can be upwards of 12 hours after commit, BUT failures in those bots
are rare, because so much other testing has gone on beforehand.
Mechanically, staging works by uploading the build artifacts to a central web
server, then passing a URL to the next set of builds so they can download the
compiler. This also speeds up builds that would otherwise have to build a
compiler to run a test. For the lab, I think that won’t work as well because of
the diversity of platforms and configurations, but a known good revision could
be passed around. Some of the fast reliable builds can run first, and publish
all the builds that work.
I do think flaky bots should only email their owners. I also think we should
nominate some reliable fast builds to produce vetted revision, and trigger most
other builds from those.
> On Oct 7, 2015, at 2:44 PM, Eric Christopher <echristo at gmail.com>
wrote:
>
>
>
> On Wed, Oct 7, 2015 at 2:24 PM Renato Golin <renato.golin at linaro.org
<mailto:renato.golin at linaro.org>> wrote:
> On 7 October 2015 at 22:14, Eric Christopher <echristo at gmail.com
<mailto:echristo at gmail.com>> wrote:
> > As a foreword: I haven't read a lot of the thread here and
it's just a
> > single developer talking here :)
>
> I recommend you to, then. Most of your arguments are similar to
> David's and they don't take into account the difficulty in
maintaining
> non-x86 buildbots.
>
>
> OK. I've now read the rest of the thread and don't find any of the
arguments compelling for keeping flaky bots around for notifications. I also
don't think that the x86-ness of it matters here. The powerpc64 and hexagon
bots are very reliable.
>
> What you're both saying is basically the same as: We want all the cars
> we care about in our garage, but only as long as they can race in F1.
> However, you care about the whole range, from beetles to McLarens, but
> are only willing to cope with the speed and reliability of the latter.
> You'll end up with only McLarens in your garage. It just doesn't
make
> sense.
>
>
> I think this is a poor analogy. You're also ignoring the solution I
gave you in my previous mail for slow bots.
>
> Also, very briefly, I want the same as both of you: reliability. But I
> alone cannot guarantee that. And even with help, I can only get there
> in months, not days. To get there, we need to *slowly* move towards
> it, not drastically throw away everything that is not a McLaren and
> only put them back when they're as fast as a McLaren. It just won't
> happen, and the risk of a fork becomes non-trivial.
>
> I think this is a completely ridiculous statement. I mean, feel free if
that's the direction you think you need to go, but I'm not going to
continue down that thread with you.
>
> Basically what I'm saying is that if you want a bot to be public and
people to pay attention to it then you need to have some basic stability
guarantees. If you can't give some basic stability guarantees then the bot
is only harming the entire testing infrastructure. That said, having your own
internal bots is entirely useful, it just means that it's up to you to
notice failures and provide some sort of test case to the community. We could
even have a "beta" bot site if something is reliable enough for that,
but not reliable enough for general consumption. I believe you mentioned having
a separate bot master before, we have other bot masters as well - see the green
dragon stuff with jenkins.
>
> -eric
>
> ps. Have actually added Chris Matthews to talk about the buildbot staging
work. Or even moving the rest of the bots to something staged, or anything. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151007/773d9359/attachment.html>