On Thu, Jan 14, 2016 at 2:43 PM, Niels de Vos <[email protected]> wrote: > On Thu, Jan 14, 2016 at 11:51:15AM +0530, Raghavendra Talur wrote: >> On Tue, Jan 12, 2016 at 7:59 PM, Atin Mukherjee <[email protected]> >> wrote: >> >> > -Atin >> > Sent from one plus one >> > On Jan 12, 2016 7:41 PM, "Niels de Vos" <[email protected]> wrote: >> > > >> > > On Tue, Jan 12, 2016 at 07:21:37PM +0530, Raghavendra Talur wrote: >> > > > We have now changed the gerrit-jenkins workflow as follows: >> > > > >> > > > 1. Developer works on a new feature/bug fix and tests it locally(run >> > > > run-tests.sh completely). >> > > > 2. Developer sends the patch to gerrit using rfc.sh. >> > > > >> > > > +++Note that no regression runs have started automatically for this >> > patch >> > > > at this point.+++ >> > > > >> > > > 3. Developer marks the patch as +1 verified on gerrit as a promise of >> > > > having tested the patch completely. For cases where patches don't have >> > a +1 >> > > > verified from the developer, maintainer has the following options >> > > > a. just do the code-review and award a +2 code review. >> > > > b. pull the patch locally and test completely and award a +1 verified. >> > > > Both the above actions would result in triggering of regression runs >> > for >> > > > the patch. >> > > >> > > Would it not help if anyone giving +1 code-review starts the regression >> > > tests too? When developers ask me to review, I prefer to see reviews >> > > done by others first, and any regression failures should have been fixed >> > > by the time I look at the change. >> > When this idea was originated (long back) I was in favour of having >> > regression triggered on a +1, however verified flag set by the developer >> > would still trigger the regression. Being a maintainer I would always >> > prefer to look at a patch when its verified flag is +1 which means the >> > regression result would also be available. >> > >> >> >> Niels requested in IRC that it is good have a mechanism of getting all >> patches that have already passed all regressions before starting review. >> Here is what I found >> a. You can use the search string >> status:open label:Verified+1,user=build AND label:Verified+1,user=nb7build >> b. You can bookmark this link and it will take you directly to the page >> with list of such patches. >> >> http://review.gluster.org/#/q/status:open+label:Verified%252B1%252Cuser%253Dbuild+AND+label:Verified%252B1%252Cuser%253Dnb7build > > Hmm, copy/pasting this URL does not work for me, I get an error: > > Code Review - Error > line 1:26 no viable alternative at character '%' > [Continue] > > > Kaushal, could you add the following labels to gerrit, so that we can > update the Jenkins jobs and they can start setting their own labels? > > http://review.gluster.org/Documentation/config-labels.html#label_custom > > - Smoke: misc smoke testing, compile, bug check, posix, .. > - NetBSD: NetBSD-7 regression > - Linux: Linux regression on CentOS-6
I added these labels to the gluster projects' project.config, but they don't seem to be showing up. I'll check once more when I get back home. > > Users/developers should not be able to set these labels, only the > Jenkins accounts are allowed to. > > The standard Verified label can then be used for manual verification by > developers, qa and reviewers. > > Thanks, > Niels _______________________________________________ Gluster-infra mailing list [email protected] http://www.gluster.org/mailman/listinfo/gluster-infra
