[Buildbot-devel] understanding buildbot & writing custom 'process'

[Stephen Davis]

On Dec 8, 2003, at 11:45 PM, Jeroen Janssen wrote:

> Now I'm trying to map this onto what I understand of buildbot.
> *) I want to seperate per product testing, this way I can choose how 
> to configure the test machines (a different PC per 
> increment/product/whatever), instead of having 'one' testSuite that 
> tests all products.

That fits in pretty well.  The "change" that triggers your build is a 
successful completion of a "real" build.  I'm not sure I'm 
understanding how you differentiate the "increments" but that shouldn't 
matter for what I say below.

> *) I will need to write a 'replacement' for the 'CVS source' in order 
> to copy the build tree results

You can just implement a ShellCommand step to copy the sources, you 
don't need to write a 'cvs source'.  The ShellCommand can execute 
whatever batch file/script you want.

> *) I will need to write a 'replacement' for cvs/mail 'changes' in 
> order to parse the build log and provide decent information to 
> buildbot (but this might be able to wait a little, because I can 
> manually trigger a slave to start doing it's work if I'm correct)

If you can run a Python script to parse incoming mail messages then 
you're golden because you can just adapt buildbot/contrib/fakechange.py 
to connect directly to the build master and trigger the build.  Also, 
look at buildbot/changes/mail.py for some parsing examples.

If you can only copy the raw mail source to a directory than I'd 
recommend using a Maildir-based source (also referenced in 
buildbot/changes/mail.py).  You just need to copy the raw email into a 
quickmail-style directory structure which you need to create ahead of 
time.  Looks like:

	cvsmail/
		new/
		cur/
		tmp/

You put the new mail in "new" and the MaildirSource will move it into 
"cur" once it finishes with it.  The existing Maildir-class will do all 
the heavy work of communicating with the build master.  BTW, you'll 
want to download release 0.4.1 b/c this was broken in 0.4.0.

I like the Maildir source model b/c if you screw something up in your 
parser then you can fix it, reload the master, and then the mail which 
is still sitting in the "new" directory will get picked up.  If you do 
the parsing as a mail filter in real-time upon delivery, you'll have to 
figure out how to re-run it manually on that message.  Note, however, 
that if you do screw up your parser then you'll get an exception and 
mail parsing will stop until you fix the parser and reload the build 
master (b/c it will keep wanting to parse the msg it can't parse and 
never get past it).

> *) I will need to 'integrate' (run) our current automatic python tests 
> into buildbot, in order for it to correctly report the testing status

I imagine you can do this with ShellCommands as well.

> I found that there is a seperate 'process' for twisted in the buildbot 
> tree, that I'm currently digging into in order to understand how to 
> extend buildbot for the above purposes.

Those are just customizations of the base classes for Twisted.  Since 
Twisted was the first customer for the buildbot, its customizations got 
included into the package.  They are handy as examples though.  :-)

> I would like to know if my current ideas on how to deal with this 
> sound ok, and maybe some hints on how other people currently deal with 
> this :)

You're not really doing anything different other than skipping the 
actual "build" step so this doesn't seem that unusual to me.  In fact, 
the buildbot doesn't care what steps it runs so it doesn't have to do 
"builds" at all.  That's a pretty important point to keep in mind when 
doing "unusual" setups -- it doesn't _have_ to follow an "update, 
build, test" model.

A tip for Windows.  You'll want to download the win32all python package 
(I forget from where, just google for it) and, when the buildbot docs 
say "twistd -f buildbot.tap...", you'll want to add "-r win32".  This 
tells Twisted to use the custom Win32 "reactor" which is a fancy way of 
saying "event loop".  :-)

Also, the bots don't seem to shut down cleanly on Windows when you hit 
ctrl-c.  I haven't bothered to try and figure out what the issue is 
since I hardly shut that bot down anymore now that it's configured 
correctly.

hope that helps,
stephen