[Buildbot-devel] Retrieving build results

[Brian Warner]

> I'd agree with Joel regarding not putting policy into buildbot. We
> currently have policy in our buildSteps and it requires too much voodoo
> when we have to release outside of the normal cycle.

I heartily agree. My build-infrastructure philosophy (developed before I ever
started Buildbot) is that all the intelligence wants to live inside the tree,
next to the source code it is managing, where it can be version-controlled
just like everything else. New developers, on their first day on the job, get
a one-page memo entitled "How To Build Our Code", with instructions that
start with a cvs/svn/etc checkout, and then a second line that says "now type
'make'", and maybe a third line that says "now type 'make test'". (I feel the
instructions should *not* involve sourcing random shell scripts to set up
PATH and such, and that the instructions should have a checklist of tools or
libraries that must be installed on the build host before starting, but I
know people who don't do it that way too).

The Buildbot should follow the same instructions as that new developer. Any
cleverness that lives outside the tree becomes harder to maintain, because
now each time you change the process, you have to teach everybody (including
the buildbot) about the new one.

I'd suggest having a 'make release' target, which creates a timestamped or
sequence-numbered release, and perhaps puts some build products (tarballs,
rpms, etc) in some well-known location. When official builds are being made,
'make release VERSION=1.2.3' can do the right thing.

> More practically, I'm thinking of having the slave send the artifacts back
> to the master and attaching them to the Build ala the logs.  I foresee
> having a status target that will be notified of the build completion and
> then be able to take appropriate action.    The other option I see is having
> buildbot post date or build number stamped artifacts to a public share but
> that doesn't seem to taste right.

So, for the next release, I'm planning on adding a new RemoteCommand[1] which
will let you fetch arbitrary files from the buildslave and have them
available to a master-side BuildStep. I also plan to add a logfiles={}
argument to step.ShellCommand, which specifies a set of (build log) files to
fetch after the shell command has run. (specifically, I have a test process
that emits some information to stdout as it runs, but which emits even more
to a node.log file in the background, and I want both to be visible in the
'testing' step's box).

I'm planning this for human-readable text-based log files, but we could use
something like this to transfer build products (tarballs, rpms, etc) from the
buildslave to the buildmaster too.

The design question that comes to my mind is what to do with these (large)
files once they arrive. I think I could imagine adding an
IBuildStatus.getProduct(name) or getFile() method, which could return an open
file handle pointing at the tarball contents or something. I'm not super
excited about the idea of large files populating the master-side Builder's
directory, but maybe with some suitable old-build-pruning code this wouldn't
seem so bad.

Of course, once the build had finished, your custom status plugin could move
the tarballs wherever they wanted. It would know the contents of the
SourceStamp and could thus determine whether the build was of the trunk, or a
'try' build, or whatever.

hmm-ingly,
 -Brian



[1]: note that RemoteCommands are lower-level than BuildSteps: each BuildStep
generally uses one or more RemoteCommands to do its job. BuildSteps run on
the master, RemoteCommands run on the slave. The step.ShellCommand uses a
single RemoteShellCommand, whereas the Trial step uses two (one to run the
tests, a second to dump the _trial_test/test.log logfile). In my planned
changes, ShellCommand would use an additional GetFileRemoteCommand for each
requested file.