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

[Pranith Kumar Karampuri]

----- Original Message -----
> From: "Anand Avati" <avati at gluster.org>
> To: "Pranith Kumar Karampuri" <pkarampu at redhat.com>
> Cc: "Justin Clift" <justin at gluster.org>, gluster-devel at gluster.org
> Sent: Tuesday, May 13, 2014 8:03:47 AM
> Subject: Re: [Gluster-devel] Automatically building RPMs upon patch submission?
> 
> On Mon, May 12, 2014 at 7:20 PM, Pranith Kumar Karampuri <
> pkarampu at redhat.com> wrote:
> 
> >
> >
> > ----- 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.
> >
> 
> Git being a DAG (upward), is trivial to get parents transitively. There is
> no natural way to get the immediate child commits of git, at least they are
> not indexed by design. We will need a way to look into gerrit's 'needed by'
> field, not sure how easy/trivial that is.
> 

According to https://review.openstack.org/Documentation/cmd-query.html there is '--dependencies' option for 'gerrit query' command to achieve that. I personally never used gerrit CLI but someone with access can probably play with it and see if it is good enough for what we want to achieve.

Pranith