Automatic buildbot verification

[David Ostrovsky]

On Thu, 2014-10-02 at 18:01 +0200, Bjoern Michaelsen wrote:
> 
> On Thu, Oct 02, 2014 at 05:48:49PM +0200, Miklos Vajna wrote:
> > Question is what would be the best to mark these changes. Should we use
> > a specially named "topic" for these changes, and reserve that name for
> > this purpose? Or should the developer just +2 the change? I'm open to
> > suggestions.
> 
> So, the canonical way is to keep "CodeReview" for human review and "Verify" for
> mechanical review. So the usual workflow is:
> 
> 1/ Patch gets uploaded

Not for this project: commits are pushed directly to git, bypassing
gerrit review branches.

> 
> This is e.g. how it works at openstack.

This is kind of useless to compare LO Gerrit workflow with OpenStack,
where reviews are mandatory and nobody can push anything bypassing
review.  Not to mention their build cluster of hundreds centralized VMs
with up to 10K builds [1] every day (source: Khai's presentation on last
Gerrit conference).

> 
> Thus a reviewer can:
> - either mark a change as +2 CodeReview, which means: "Merge directly when it
>   builds/tests successfully."
> - or mark a change as +1 CodeReview, which means: "Testbuild this, but dont automerge."
> 

What we need is to seamlessly support 3 different LO Gerrit workflows:

a) contributor push a change for review
b) committer push a change to release branch for multiple reviews
c) committer push a change to master for verification only + auto-merge

> Also note that in we could customize gerrit to have an additional row beyond
> "CodeReview" and "Verified". gerrit supports as many custom rows as you like
> there. But I really think that is a bad idea. CodeReview and Verified are
> exactly what we need -- no additional stuff to document and confuse newcomers
> needed.
> 

Nobody said that newcomers should be able to "mark" or better to say
activate c) worklfow above: they can only do a) and b). They cannot
schedule gerrit-buildbot-build today as well (and have to ask).

To support workflow c) new "label" (what you called "row") is needed,
for example OpenStack has introduced new "Workflow"-Label and abused it
for two different purposes: Workflow-1 means: this is Work In Progress
(WIP) change and is filtered out from custom dashboards. Workflow+1
means the change is approved in addition to Code-Review+2, so that Zuul
(their python based queue manager) can merge this change.

IOW we could introduce new label, say Worklfow, and activate it by
uploading a change with direct voting feature during upload (what i've
contributed upstream [2]):

  git push logerrit:HEAD:refs/for/master%l=Worklow+1,l=Coder-Review+2
[*]

Of course this workflow can be activated by limited group of peoples
after the upload. For all changes that were marked as Workflow+1,
buildbot build is scheduled automatically. All changes that have
Workflow+1, Coder-Review+2 and Verify+1 are get merged automagically.

[*] By putting this review-approve alias in your .gitconfig file you
could save some typing:

[alias]
  r-a = push logerrit HEAD:refs/for/master%l=Worklow+1,l=Coder-Review+2

[1] http://status.openstack.org/zuul/
[2] https://gerrit-review.googlesource.com/56712