Re: Coping with the pull-before-you-push model

[David Brown <davidb@codeaurora.org>]

On Tue, Sep 14, 2010 at 01:24:51AM -0400, Jeff King wrote:

> I seem to recall from one of Shawn's presentations on Gerrit Code Review
> that it does something like this, too, but I can't seem to find any docs
> about it in my brief search:
> 
>   http://code.google.com/p/gerrit/
> 
> It may be that Gerrit doesn't handle building itself, but that the
> Android project is running something alongside it. Shawn may be able to
> say more.
> 
> Basically, what we are talking about is continuous integration, with the
> slight twist that instead of developers pushing commits to a mainline
> branch which is built and tested, we would build and test their commits
> and then merge them to the mainline branch.

Gerrit doesn't do the build and test, but it isn't all that difficult
to hook into.  It also allows the results of the build and test to
record their state so that the developer can track what is happening.

The nice part about it, compared to other CI systems I've seen is that
it catches the problems before they are merged into master, rather
than after.

Internally, we actually do multiple levels of a CI-type thing.  Every
time a developer uploads a change, one machine performs a sanity build
on it (with multiple configurations).  These results are visible in
Gerrit, and it keeps people from putting too much effort into
reviewing code that doesn't even compile.

Once the code has gotten through two levels of code review, a more
throughough build and test system pulls the whole project (from
numerous git repos) builds and runs tests.  This takes long enough
that it doesn't do individual changes, so failures take work to track
down, but it does generally assure that the result of each 'git merge'
somewhat works.

The only real annoying part I've found with the gerrit model is that
the tree is filled with lots of merge comments (generally a merge for
every real commit).  The other option is to let Gerrit rebase, which
then gets annoying when a developer has pulled changes from other
developers.

It also has a nice link to a 'git pull' command to pull down an
individual change.

David