[Buildbot-devel] project and repository

[Dustin J. Mitchell]

Dan Locks and I talked for a while today about how to integrate these
changes into the latest buildbot.  Let me see if I can summarize.

Dan would like to have a "project" identifier that indicates the
project to which the change applies.  This is useful for organizations
that want to build multiple projects in one buildmaster.  For example,
Gnome might want to build all of their projects (see
http://svn.gnome.org/viewvc/) in one buildmaster, and the "project"
identifier would facilitate this by tagging a change to e.g.,
gnome-lokkit/trunk/configure.in as corresponding to the "gnome-lokkit"
project.  A scheduler could then match against this project and only
trigger the builder(s) relevant to that project.  The change
"category" is often used for this purpose, but it does not persist
into the SourceStamp and build, and isn't displayed in status output.

Benoit Allard would like to have a "repository" identifier that adds
the missing piece of information in a SourceStamp: the repository from
which to check out the given revision and branch.  This has
historically not been necessary, because Source steps receive the
repository in their constructor, e.g., SVN(svnurl="..").  This
specification, however, is redundant and has an, um, "complex"
relationship to the URL given to the SVNPoller.  With Ben's suggested
change, this constructor parameter would no longer be necessary.  This
simplifies the configuration, but the more significant advantage is
that it means the same BuildFactory can be used for a number of
projects (presumably with mode="clobber"!).  Returning to the Gnome
example, most Gnome projects follow a strict autoconf-based build
process, so a single buildfactory could be used to build any of them.

Brian's DB work has encapsulted both Changes and SourceStamps in the
database.  So to make these changes, we will need to add 'project' and
'repository' columns to the changes and sourcestamps tables, then
adjust the change sources appropriately, and finally adjust the
schedulers (for project) and source steps (for repository).

Between Dan's patches and Ben's patches, most of this is done -- it's
just a matter of merging it all together and making sure it's
backward-compatible.  Which I'll work on.

Dustin

-- 
Open Source Storage Engineer
http://www.zmanda.com