Jenkins
Nigel Babu edited this page Sep 26, 2016
·
2 revisions
We need to change how voting works on Jenkins. Our current workflow is non-optimal for many of our own use case.
- If you submit a change, give it a Verified +1 flag, we'll kick of regressions. If you change your commit message before regressions come back, regressions will vote on the previous patch.
- This a smaller concern, but having the ssh key to vote on Gerrit on every server sounds a bit non-ideal. For example, when people request loaner machines, we need to remove the key and place it back. Or (as we've been doing), inadvertently give them access to the key.
- Gerrit and Jenkins are integrated tightly around the Verified and Code Review flags. Zuul is also currently tied into this integration. It will get better, but that's probably not part of their initial release.
We need to switch our workflow slightly to something like this.
- Submit a patch for review. By default it's set to draft state. This can be viewed by reviewers who are added by name (we can default to having maintainers being able to see drafts).
- Once the patch moves from Draft to Published, we'll run smoke tests and regression tests. I'm contemplating a two-step process here where Regression jobs are triggered after a successful pass of the smoke test.
- Once regression tests are complete, Jenkins will vote on Verified +1 for all the jobs.