Re: Solve continuous integration (pending head / commit queue) problem using git

[Jan Koprowski <jan.koprowski@gmail.com>]

On Fri, Feb 12, 2010 at 6:42 PM, Avery Pennarun <apenwarr@gmail.com> wrote:
> On Fri, Feb 12, 2010 at 11:37 AM, Jan Koprowski <jan.koprowski@gmail.com> wrote:
>> Now. My idea. There is some revision tagged as "stable". *Clone* and
>> *pull* operations is somehow "overloaded" from server side and always!
>> return last revision tagged as stable. After compiling external tool
>> just move tag to another revision which pass all tests. Of course
>> there is some additional parameter (for example --last or --unstable)
>> which can clone fine way of repository.
>>
>> Two questions.
>> 1) Maybe I try to invent the wheel again. Is there any way to take the
>> effect without overloading standard git behaviours.
>> 2) If not how overload git behaviors on git "server side" repo?
>
> In general, code that lies to you about what's the most revision is
> evil.  Sometimes you *do* want to fetch that revision it's lying to
> you and saying doesn't exist, precisely because you'd like to help fix
> it before integration.
>
> What you really want is:
>
> - nobody can push to the "integration branch" except the "integration manager"
>
> - the "integration manager" should be a computer program, so that you
> can have "continuous integration"
>
> This isn't actually that hard.  Give each user their own repository;
> no user can write to any other user's repository.  (This is the
> default setup on github.com, for example.)  Alternatively, just tell
> people to never, ever push to the master branch by themselves.  People
> are easily capable of following rules like that unless they're
> actively trying to screw you.
>
> Then set up something like gitbuilder
> (http://github.com/apenwarr/gitbuilder) (Full disclosure: I wrote it)
> to build *all* the branches from *all* the users.  This sounds like it
> would create exponential work for the build machine, but it doesn't,
> since most users will have mostly the same commits anyway.
>
> When gitbuilder tags a particular commit as having built and passed
> all tests, then it becomes a candidate for merging into the
> integration branch.  Write a little script that goes through candidate
> branches, checks their gitbuilder status, and if they've passed,
> pushes them into the integration branch.  The push will only succeed
> if the integration branch can be fast-forwarded to match the branch
> you're trying to push; if you can't, it'll be rejected, which is what
> you want, since merging (even conflict-free merging) might break
> tests.
>
> That mechanism works pretty well at my company, with one exception: we
> didn't bother with an automatic tool that merges into master.  We
> prefer to have a release manager do that.
>
> Have fun,
>
> Avery
>

Probably I don't have a problem (or it is a lateness). Because only
tagging as stable and making two compile loops: one per management
always compiling stable tag and second compiling latest repo... And
that is all :D

-- 
><> Jan Koprowski [696775174] GSM