On 22 Apr 2015, at 15:39, Jeff Darcy <jdarcy@xxxxxxxxxx> wrote: >> As we know, we have a patch from Manu which re-triggers a given failed >> test. The idea was to reduce the burden of re-triggering the regression, >> but I've been noticing it is failing in 2nd attempt as well and I've >> seen this happening multiple times for patch [1]. I am not sure whether >> I am damn unlucky or we have a real problem here. >> >> Any thoughts? > > Many of the most common spurious failures seem timing-related. Since > the timing on a particular node is unlikely to change between the first > failure and the retry, neither is the result. Running the retries on > another node might work, but would be very complex to implement. For > the time being, I think our best bet is for the tests identified in > this patch to be excluded/ignored on NetBSD as well: > > http://review.gluster.org/#/c/10322/ > > That might significantly cut down on the false negatives. When tests > still fail, we're stuck with re-triggering manually. Jenkins has some kind of API (haven't looked at it), so we might be able to do something with the API to automatically add the failed CR to the regression queue again. That would have a reasonable change of running it on a different node. + Justin -- GlusterFS - http://www.gluster.org An open source, distributed file system scaling to several petabytes, and handling thousands of clients. My personal twitter: twitter.com/realjustinclift _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
