On Fri, Aug 02, 2013 at 02:02:34PM +0530, Varun Shastry wrote: > > On Wednesday 31 July 2013 05:17 PM, Kaleb S. KEITHLEY wrote: > >On 07/31/2013 07:35 AM, Amar Tumballi wrote: > >>Hi, > >> > >>I was trying to fire some regression builds on very minor patches today, > >>and noticed (always known, but faced pain of 'waiting' today) that we > >>can fire regression build on only one patch (or a patchset if its > >>submitted with dependency added while submitting). And each regression > >>run takes approx 30mins. > >> > >>With this model, we can at max take only ~45 patches in a day, which > >>won't scale up if we want to grow with more people participating in code > >>contribution. Would be great to have an option to submit regression run > >>with multiple patch numbers, (technically they should be applicable one > >>top of other in any order if not dependent), and it should work fine. > >>That way, we can handle more review load in future. > > > >When a regression fails how do you know who to blame? > > We test multiple patches (say 10) at a time; fall back to previous > model of one test per patch when regression fails (we can also > employ binary search to find the patch causing the regression > failure). Isn't this plausible? In fact, this can be automated pretty easily with 'git bisect'. It seems that there is a feature request for Jenkins already: - https://issues.jenkins-ci.org/browse/JENKINS-12972 I have no idea about the internals of Jenkins, so I can not really help with pushing this. Cheers, Niels > > - Varun Shastry > > > >I'd rather see more build machines (multiple VMs on a big > >build.gluster.org replacement box?) instead to get more > >concurrency. > > > > > > > _______________________________________________ > Gluster-devel mailing list > Gluster-devel@xxxxxxxxxx > https://lists.nongnu.org/mailman/listinfo/gluster-devel -- Niels de Vos Sr. Software Maintenance Engineer Support Engineering Group Red Hat Global Support Services
