[Buildbot-devel] precommit build

[Brian Warner]

> Brian, buildbot  works fine with  cvstoys. Thanks   for your support .

Glad to hear it. If there are any notes you think should be added to the docs
that would help others, please let me know.

> Is there any way that I can do a precommit build , I mean.... the user
> must be able to checkin the code only if  the build is successful ,if
> not the code should not go into the repository. Thanx  in advance

Well, there are two separate pieces here, and the buildbot can only help with
one.

The first is how to answer the question "will my (uncommitted) code build
successfully on all (or some subset of) the Builders?". The new 'buildbot
try' feature is specifically designed to answer this question. You run it on
your local tree, it sends a job request to the buildmaster with enough
information to reproduce your tree on the buildslaves, then runs a build. You
are then told whether the build succeeded or not.

The second part is how to enforce the rule that you cannot commit a change
until some criteria has been met. This is more of a question for the VC
system you are using than for the buildbot. Some systems offer pre-commit
hooks that can run commands and abort the checkin if they fail. Some of them
encourage using these hooks specifically to do the sort of unit-testing
you're suggesting. You might be able to run 'buildbot try' from within one of
these hooks, but 'buildbot try' is currently aimed at developers rather than
as a scriptable tool (specifically I'm not sure I set the exit code usefully
yet). Also the hooks are usually meant to be fairly fast, and running a 'try'
build on a bunch of different Builders could take a long time, depending upon
how busy those machines are. While the precommit hook is running, you
probably won't be able to do anything else in that tree.

Another possibility, if you use one of the flexible VC systems like Darcs or
Arch, would be to have developers commit to a "waiting area" branch instead
of the publically-visible trunk. The buildbot could run tests against any
changes that occurred on that branch, and a status plugin could watch for
successful builds. If the build is successful, the plugin could automatically
merge those changes over into the main trunk. You'd have to toy with this a
bit, it would probably work better to have each developer get their own
"published" branch and then have one common "only the working stuff" branch
which is maintained by this status plugin. For Darcs this would be pretty
straightforward, developers would push to their published branch and then
pull from the common one.

Monotone lets you set arbitrary attributes on individual changes (called
"revisions" in monotone-speak), and then construct a tree using only the
revisions which meet certain criteria. You could have a status plugin that
sets a "tested=True" attribute on every Change that went into a good build,
and then encourage developers to use trees that used this as a revision
filter. That way they would never see the changes that failed a build. You'd
still have to figure out some details: if the buildbot is always building the
unfiltered "trunk", then once a bad change went in, all further builds would
fail, causing other (innocent) revisions to be denied too. Plus you'd have to
figure out how to get those revisions marked good again once the fix had been
committed.

Also, we'd have to finally merge njs's Monotone changes into the tree :).
Maybe this weekend I'll try to find some time for that.

hope that gives you some ideas,
 -Brian