On Mon, May 12, 2014 at 5:16 PM, Justin Clift <justin@xxxxxxxxxxx> wrote:
Heh, bad wording. Was meaning "doesn't that just test the givenOn 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)
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.
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
