[Gluster-infra] Gerrting Voting Problems
nigelb at redhat.com
Thu Feb 23 12:29:18 UTC 2017
I know we've had Jenkins voting issues for a while and I'd like to offer tips
to avoid the worst of it.
1. Do not set a Verified +1 flag until smoke tests have reported back. If you
do, all jobs will vote together. This will cause smoke tests or regressions
to vote incorrectly.
2. If you have a regression job running, do not rebase the patch or edit the
commit message until the job has voted. You cannot merge until the vote
comes through anyway. If you edit the commit message or rebase, Jenkins will
vote will behave incorrectly.
## Root Cause
The first problem is caused by how we've setup Jenkins and voting. The
regression jobs vote as part of the job. The vote for the smoke tests are
managed by Jenkins. To handle this, we have two Gerrit servers with the same
domain (review.gluster.org) setup on Jenkins. When a smoke job and regression
job finishes at the same time, it might report to either server. It may or may
not vote depending on which Gerrit server Jenkins decides to report back to.
This is what I'm working on fixing.
The second part happens because a job has an environment variable with the
patchset (Ex 1234/5). If you change your commit message or rebase your change,
you create a new patchset (1234/6). If a job is already running, against the
old patchset (1234/5), it will vote on (1234/5), which doesn't count. This will
continue to happen. So, it's very important to remember *not* make a change
until all running jobs have finished.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: not available
More information about the Gluster-infra