<p dir="ltr"><br>
On 30 May 2015 20:38, "Niels de Vos" <<a href="mailto:ndevos@redhat.com">ndevos@redhat.com</a>> wrote:<br>
><br>
> On Sat, May 30, 2015 at 01:19:02PM +0200, Niels de Vos wrote:<br>
> > Hi all,<br>
> ><br>
> > many of the Jenkins regression-tests have finished before all the smoke<br>
> > jobs were done (we have fewer NetBSD slaves and the smoke tests were<br>
> > waiting long in the queue). This caused the Verified +1 from the<br>
> > regression-tests to be overwritten with Verified=0 once the smoke<br>
> > results were available.<br>
> ><br>
> > The configuration change I have made in the several Jenkins jobs that<br>
> > are doing smoke testing, is like this:<br>
> ><br>
> > - open a Jenkins job configuration<br>
> > - scroll down to "Gerrit trigger"<br>
> > - click the [Advanced...] button<br>
> > - scroll down to "Gerrit Reporting Values"<br>
> > - enable "Skip Vote" for "Successful"<br>
> > - click the [Save] button on the bottom of the page<br>
> ><br>
> > This means that any successful result (Verified=0) will not get passed<br>
> > on to Gerrit. If the regression test finished before, it will not be<br>
> > overwritten anymore. This not-overwriting will be marked in a comment in<br>
> > Gerrit with "SUCCESS (skipped)" next to the job. If a smoke test fails,<br>
> > the failure will be reported and Verified=-1 gets set.<br>
> ><br>
> > Well, that is the/my theory at least. Let me know if you notice any<br>
> > issues.<br>
><br>
> Unfortunately, this does not seem to work :-/ When all smoke tests<br>
> succeed and get marked as "skipped", the voting is still setting<br>
> Verified=0 and with that overwriting a possible Verified=+/-1 from the<br>
> regressions tests.<br>
><br>
> So, the other solutions would be:<br>
><br>
> a. chaining of Jenkins jobs (1. smoked -> 2. regressions)<br>
> b. post results of the smoke test as different users<br>
><br>
> The problem with "b" is that there is no requirement to wait for all<br>
> responses from Jenkins. Once there is one Verified=+1, patches can get<br>
> merged. Maintainers are supposed to check the passing of all required<br>
> regression tests, but they do get missed on occasion.<br>
Makes sense to me, if we can achieve 'a' then definitely its a better option over 'b'.<br>
><br>
> Ideas and suggestions welcome.<br>
><br>
> Thanks,<br>
> Niels<br>
> _______________________________________________<br>
> Gluster-devel mailing list<br>
> <a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a><br>
> <a href="http://www.gluster.org/mailman/listinfo/gluster-devel">http://www.gluster.org/mailman/listinfo/gluster-devel</a><br>
</p>