----- Original Message ----- > From: "Anand Avati" <avati@xxxxxxxxxxx> > To: "Pranith Kumar Karampuri" <pkarampu@xxxxxxxxxx> > Cc: "Justin Clift" <justin@xxxxxxxxxxx>, gluster-devel@xxxxxxxxxxx > Sent: Tuesday, May 13, 2014 8:03:47 AM > Subject: Re: Automatically building RPMs upon patch submission? > > On Mon, May 12, 2014 at 7:20 PM, Pranith Kumar Karampuri < > pkarampu@xxxxxxxxxx> wrote: > > > > > > > ----- Original Message ----- > > > From: "Anand Avati" <avati@xxxxxxxxxxx> > > > To: "Justin Clift" <justin@xxxxxxxxxxx> > > > Cc: gluster-devel@xxxxxxxxxxx > > > Sent: Tuesday, May 13, 2014 5:50:07 AM > > > Subject: Re: Automatically building RPMs upon patch > > submission? > > > > > > > > > > > > > > > On Mon, May 12, 2014 at 5:16 PM, Justin Clift < justin@xxxxxxxxxxx > > > wrote: > > > > > > > > > > > > On 13/05/2014, at 1:00 AM, Anand Avati wrote: > > > > On Mon, May 12, 2014 at 4:39 PM, Justin Clift < justin@xxxxxxxxxxx > > > 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 _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
