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

From: David Brown <davidb@codeaurora.org>
Date: Sep 15, 2010, 21:59 UTC
Message-ID: <20100915215954.GA20880@huya.qualcomm.com>
In-Reply-To: <20100914052451.GA15839@sigill.intra.peff.net>

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

Show 14 quoted lines

> 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