<div dir="ltr"><div>I wonder if it would be possible to make some recommendations for improvements based on data rather than our collective anecdotal experience. Much as anyone else, I feel that the vast majority of the failure emails I get are not related, but I would have a lot of trouble quantifying it any better than a "gut feeling".</div><div><br></div><div>Would it be possible to somehow acquire historical data from buildbots to help identify things that can improve. Perhaps:</div><div>- Bot failures where none of the commits were reverted before the bot went back to green</div><div>- For those failures, collect the test cases that failed - those might be flaky test cases if they show up frequently and/or on multiple bots<br></div><div>- For bots that have many such instances (especially with different test cases every time), perhaps the bot itself is somehow flaky<br></div><div><br></div><div>This is definitely an annoying problem that has significant consequences (real failures being missed due to many false failures), but it is a difficult problem to solve.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 22, 2021 at 5:50 AM Martin Storsjö via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, 22 Sep 2021, Florian Hahn via llvm-dev wrote:<br>
<br>
> Thanks for raising this issue! My experience matches what you are<br>
> describing. The false positive rate for me is seems to be at least 10 false<br>
> positives due to flakiness to 1 real failure. <br>
> I think it would be good to have some sort of policy spelling out the<br>
> requirements for having notification enabled for a buildbot, with a process<br>
> that makes it easy to disable flaky bots until the owners can make them more<br>
> stable. It would be good if notifications could be disabled without<br>
> requiring contacting/interventions from individual owners, but I am not sure<br>
> if that’s possible with buildbot.<br>
<br>
Another aspect is that some tests can be flakey - they might work <br>
seemingly fine in local testing but start showing up as timeouts/spurious <br>
failures when run in a CI/buildbot setting. And due to their flakiness, <br>
it's not evident when the breakage is introduced, but over time, such <br>
flakey tests/setups do add up, to the situation we have today.<br>
<br>
// Martin<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>