[Buildbot-devel] Build numbers?

[Brian Warner]

> How do the buildbot users out there implement and maintain consistent
> build numbering?

What exactly do you mean by "build numbering"? I.e., what is the scope of
such a number: is it supposed to be valid forever? Are multiple builds (on
different platforms) supposed to have the same number?

Buildbot-0.6.0 has the notion of "source stamps", which (for CVS) is a
timestamp used for the checkout. (for SVN it is the revision number, which is
a much cleaner way to go). The repository+source-stamp pair is a unique,
ever-valid identifier of what source code went into the build. Assuming you
keep your build process consistent, and your build hosts uniform, it will be
an eternally-valid identifier of what compiled/tested results come out of
that source code.

There is an API in the IBuildStatus interface which allows you to fetch the
source stamp for any build. You could probably rig up a Status receiver to
pull these out and then perform a 'cvs rtag' from the timestamp. There are a
couple of issues:

 What to label the tag (CURRENT_WORKING? sequential numbers?).

 How to perform the label: the buildmaster process does not typically have
 access to the CVS archive (only the buildslaves really need it). You'd have
 to set things up so that the buildmaster (or a remote process connected to
 the PB status interface) had the appropriate permissions to manipulate the
 CVS repository.

 How to deal with multiple builders: each builder runs separately (since they
 may each have different rules for ignoring/accepting Changes, and their
 slaves may be busy or offline at different times so some builds may get
 merged). At the moment there is no attempt to coordinate source stamps
 between builders, so you'd wind up with multiple tags per Change
 (CURRENT_WORKING_I386, CURRENT_WORKING_POWERPC, etc).

However, none of those are fatal issues. The third could be dealt with nicely
by having a "stamper" build that depends upon all arches working, which
wouldn't compile or test but might just build a tarball; then the source
stamp used for that build could be used for the cvs tag. This will do the
right thing because of the way Interlocks (which really really need to be
renamed to Dependencies') are implemented: the dependent build will be
performed with the same set of Changes as the feeder builds.

> We've already got some pre-buildbot numbering that we'd like to get in step
> with, or possibly even adopt a new numbering system, but just be able to
> implement it consistently across the various different builders and
> buildslaves.

Another question to consider is how those numbers are stored. I had one
environment (using SCCS, but that's beside the point) which used a 'seed'
file that consisted of a few thousand lines of filename/version-number pairs.
A tree was described by a seed, and the seed file was itself checked in. The
overall build was thus completely described by the version number of the seed
file, providing your 'build number'. (SVN and Perforce give you something
sorta similar to this with their monotonically-increasing revision numbers,
the difference being that their revision numbers imply inclusion of all
previous changes, whereas seed-v124 could be completely unrelated to
seed-v123).

Or, you rotate the data structure 90 degrees, and you wind up with a CVS tag
for each numbered build (the lines of the seed file are effectively
distributed out to the individual source files). Each approach gives you
different benefits.

Hopefully some other folks will chime in on their experiences. So far I've
only used buildbot for -r HEAD testing, but it would be nice if it could
easily produce -r CURRENT_WORKING -style tags.

cheers,
 -Brian