If an intermittent failure happens in an auto-rollup job, it'll just split it and run all the tests again on the halves. Assuming the intermittent is rare, both those halves will probably pass and it'll land. It has log[2]N tries before it gives up.
If the intermittent is common, we want to do what we currently do. Disable it and forget^H^H^H^H^H^H^H fix it as we get a chance to do so. On Tue, Aug 9, 2016 at 4:57 PM Olaf Buddenhagen <olafbuddenha...@gmx.net> wrote: > Hi, > > On Thu, Aug 04, 2016 at 09:41:00AM -0600, Jack Moffitt wrote: > > > > My point is that I believe it's possible to create a setup doing full > > > pre-commit testing -- with all the advantages it brings over > post-commit > > > testing -- while avoiding the scalability problems of the existing > setup > > > is Servo. > > > > It depends what you mean by scalability. Doesn't pipelining the tests > > require # PRs in queue * builders number of builders? > > If we do not cap the number of speculative test runs, it means the > number of jobs will equal the number of PRs in the queue. Is that what > you are asking? > > (We *can* put a cap on it though if so many PRs queue up that it would > become a serious problem...) > > > This seems to trade time for machines by optimistically assuming all > > previous PRs passed tests. > > Right. > > As long as intermittent failures are rare, I think it's a fair > assumption. (Actual bugs showing up in pre-commit testing should be > fairly rare, as most are already found by automated PR testing and > optional manual try runs...) > > If we *do* have to deal with frequent intermittent failures, the many > speculative runs can actuall come in handy, as I explained in the other > followup. > > -antrik- > _______________________________________________ > dev-servo mailing list > dev-servo@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-servo > _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
