[Gluster-devel] [Feature request]: Regression to take more patches in single instance
Niels de Vos
ndevos at redhat.com
Fri Aug 2 09:50:38 UTC 2013
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 at nongnu.org
> https://lists.nongnu.org/mailman/listinfo/gluster-devel
--
Niels de Vos
Sr. Software Maintenance Engineer
Support Engineering Group
Red Hat Global Support Services
More information about the Gluster-devel
mailing list