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

[Jeff King <peff@peff.net>]

On Mon, Sep 13, 2010 at 10:47:30PM -0600, Joshua Jensen wrote:

> >Bear in mind that you can still shift to a maintainer model, but keep
> >the maintainer automated. That is, you can queue up "to-pull" heads, and
> >then have an automated process pull them one by one and do some basic QA
> >(does it merge, does it build, does it pass automated tests, etc). Which
> >is not that different from what many shops do in the non-maintainer
> >model, except that when you break the build, the maintainer process
> >notices _before_ publishing the merged tip, so everybody won't try to
> >build on your broken crap.
> >
> Do you know of any existing software that does this?  This may be
> ideal in the short term.

I think that Avery Pennarun's gitbuilder may do what you want:

  http://github.com/apenwarr/gitbuilder/

but I've never used it.

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.

Systems like Hudson that do continuous integration and support git may
handle a workflow like this, but I don't know (I've only ever used
Hudson in the everything-goes-to-svn-trunk model).

There is also a small continuous integration system that lives in the
contrib/continuous directory of git.git itself. It's quite old at this
point, but I wouldn't be surprised if its descendant is what Gerrit
uses.

-Peff