Re: Test that every revision builds before pushing changes?

[Andreas Ericsson <ae@op5.se>]

Daniel Pittman wrote:
> Andreas Ericsson <ae@op5.se> writes:
>> Daniel Pittman wrote:
>>> I would like to ensure that my commits are fully bisectable before I
>>> commit them to an upstream repository, at least to the limits of an
>>> automatic tool for testing them.
>>>
>>> 'git bisect run' is similar: it can automatically locate the breaking in
>>> a test suite, for example, but that doesn't help me in the case of three
>>> commits, A (good), B (bad) and C (good, fixing B).
>>>
>>> I would much rather, in this case, use rebase to fix B so that it, too,
>>> builds before I push the changes and pollute a public repository with a
>>> broken changeset — and make bisect that much harder to use in future.
>> You can do that, but it requires manual work too. The trick is to make
>> the release branch immutable on the public repository and use topic
>> branches with per-developer namespaces. The per-developer namespace
>> thing is actually important, as it leaves the freedom to rewind and
>> recreate topics to the developers (which shared branches do not).
>>
>> The manual step comes at merge-time; Someone has to be responsible for
>> merging all the topics that are to be included in the release branch
>> and make sure it builds and passes all tests after each merge.
> 
> Ah.  You have not quite grasped what I was looking for: I was after a
> tool to help automate that step, rather than a workflow around it.
> 

Oh right. Sorry, I'm stuck in continuous-integration land where people
tend to want the server to take care of such things.

> For example, the responsible person for that testing could use the
> hypothetical (until someone tells me where to find it):
> 
>     git test public..test make test
> 
> Which would then effectively wrap:
> 
>     for each revision between public and private:
>          git checkout revision
>          make test
>          # report if that fails, allow fixing the commit or whatever
>          # then 'git test continue' to carry on...
> 
> That turn the process from a manual one to an automated one: it runs
> that command for every revision until it fails, or until they all pass.
> 

Something like this?
--%<--%<--
#!/bin/sh

git stash
revspec="$1"
shift
for rev in $(git rev-list "$revspec"); do
	git checkout $rev
	"$@" || break
done
--%<--%<--

Run it as such:
./git-test.sh public..test make test

Adding support for "continue" in there shouldn't be hard, since
you'd just replace the first rev with the first parent of the
last tested revision, although if you want to fix up a commit
in the middle, you'd have to manually rebase the other ones
onto the newly created commit (again, not very hard but I'll
leave both as an exercise to you).

It doesn't handle merges very nicely, btw, but I guess this
should be run prior to merging anyways.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.