[Gluster-devel] Automatically building RPMs upon patch submission?

[Pranith Kumar Karampuri]

----- Original Message -----
> From: "Anand Avati" <avati at gluster.org>
> To: "Justin Clift" <justin at gluster.org>
> Cc: gluster-devel at gluster.org
> Sent: Tuesday, May 13, 2014 5:50:07 AM
> Subject: Re: [Gluster-devel] Automatically building RPMs upon patch	submission?
> 
> 
> 
> 
> On Mon, May 12, 2014 at 5:16 PM, Justin Clift < justin at gluster.org > wrote:
> 
> 
> 
> On 13/05/2014, at 1:00 AM, Anand Avati wrote:
> > On Mon, May 12, 2014 at 4:39 PM, Justin Clift < justin at gluster.org > wrote:
> > On 13/05/2014, at 12:27 AM, Anand Avati wrote:
> > <snip>
> > > http://build.gluster.org/job/regression/build - key in the gerrit patch
> > > number for the CHANGE_ID field, and click 'Build'.
> > 
> > Doesn't that just apply the given change to HEAD of its
> > associated branch? eg it won't apply dependent commits
> > first?
> > 
> > No, this is just for jenkins to run tests and vote on gerrit. Applying a
> > change into HEAD is done by sub/maintainers having commit rights to the
> > project in Gerrit. However Gerrit prevents even a maintainer from
> > committing until there is +2 code review vote and +1 verified vote (no
> > matter who votes - Jenkins or someone else)
> 
> Heh, bad wording. Was meaning "doesn't that just test the given
> patch applied to HEAD for it's associated branch?". Wasn't meaning
> actually committing it back to the repo. ;)
> 
> Thinking about it more, if we're just testing _too many_ things
> it's likely only a problem short term. When we get the regression
> testing parallelised (soon), then it shouldn't really matter much.
> 
> Ah, I see what you meant. Specifying a gerrit patch# as CHANGE_ID will apply
> that patch and all its dependent (unmerged yet) gerrit patches on top of
> HEAD and run the tests. If test fails, then the entire patch set is voted
> -1, not just the CHANGE_ID specified.

Avati/Justin
If we are going to start the regression after the smoketest completes, most likely all the dependent/needed-by patches are submitted by then. So just as we try to figure out the 'depends on' patches won't we be able to figure out 'needed by' patches? If we can, then the only problem is to figure-out if we had already launched a regression test for that 'top' patch to prevent triggering duplicate regressions. If we want to be more precise we can even wait for smoketests of the whole patch set to complete before triggering the regression.

Pranith.

> 
> 
> 
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-devel
>