[Gluster-infra] [Gluster-devel] Reconfigured Jenkins (smoke) jobs to not overwrite/reset regression-test results
Niels de Vos
ndevos at redhat.com
Sat May 30 12:14:53 UTC 2015
On Sat, May 30, 2015 at 05:05:57PM +0530, Atin Mukherjee wrote:
> On 30 May 2015 16:49, "Niels de Vos" <ndevos at redhat.com> wrote:
> > Hi all,
> > many of the Jenkins regression-tests have finished before all the smoke
> > jobs were done (we have fewer NetBSD slaves and the smoke tests were
> > waiting long in the queue). This caused the Verified +1 from the
> > regression-tests to be overwritten with Verified=0 once the smoke
> > results were available.
> > The configuration change I have made in the several Jenkins jobs that
> > are doing smoke testing, is like this:
> > - open a Jenkins job configuration
> > - scroll down to "Gerrit trigger"
> > - click the [Advanced...] button
> > - scroll down to "Gerrit Reporting Values"
> > - enable "Skip Vote" for "Successful"
> > - click the [Save] button on the bottom of the page
> > This means that any successful result (Verified=0) will not get passed
> > on to Gerrit. If the regression test finished before, it will not be
> > overwritten anymore. This not-overwriting will be marked in a comment in
> > Gerrit with "SUCCESS (skipped)" next to the job. If a smoke test fails,
> > the failure will be reported and Verified=-1 gets set.
> > Well, that is the/my theory at least. Let me know if you notice any
> I would suggest to have 3 acks, a separate vote id for smoke as well.
Yes, that would be an option as well. But I do not (yet) know how to set
that up :-)
However, I prefer to only start the regression tests once the smoke
tests have successfully finished. In that case, smoke will still not +1
the change, and leave that over to the regression tests.
The smoke tests (if scheduled directly) take about 30 minutes to run
(netbsd6-smoke takes longest, 5 minutes on Linux/FreeBSD?!). I think we
should look into that, and then we can configure the chaining of jobs,
without delaying the results of the regression tests too much.
> > issues.
> > Thanks,
> > Niels
> > _______________________________________________
> > Gluster-devel mailing list
> > Gluster-devel at gluster.org
> > http://www.gluster.org/mailman/listinfo/gluster-devel
More information about the Gluster-infra