[Buildbot-devel] possible to add new VC to master.cfg?

[Brian Warner]

> The project I work with, openoffice.org, uses a specialized version
> control system (a layer on top of CVS).  Our VC system is fairly
> straightforward.  We have a perl script that grabs the files from the VC
> system.  It takes in two arguments, mode (co/up) and tag/branch.

Have you considered just using a regular ShellCommand? If you're mostly just
updating to the most-recent version, then you may not need to use anything
derived from the existing VC classes.

> Since it is desirable to have the slaves using the upstream version of
> buildbot, it seems that it is desirable to put custom classes in
> master.cfg.

You can put these classes in master.cfg directly, or in another file which is
included by it. Take a look at
<http://buildbot.sourceforge.net/manual-0.7.5.html#Adding-LogObservers>
(which is a subsection of the "Writing New BuildSteps chapter) for an example
of the different places you can put custom BuildStep classes and the relative
advantages/disadvantages of each.

> However, I am having trouble adding my new subclasses of
> Source and SourceBase in master.cfg.  In the respective source.py and
> commands.py files, I find that the classes for the VC systems are named
> the same (CVS(Source): and CVS(SourceBase):).  Firstly, I don't really
> understand what the purpose of these two different sets of classes are.

Take a look at the files where those classes are defined. The first is a
master-side file (defined in buildbot/steps/source.py, which is used
exclusively on the buildmaster side, and defines BuildStep classes which can
be referenced from within the master.cfg file). The second is a slave-side
file (defined in buildbot/slave/commands.py, which is used exclusively on the
buildslave-side).

The master-side master.cfg file defines a Builder with a Factory with a bunch
of BuildSteps, including steps like CVS and ShellCommand. These BuildSteps
may use one or more RemoteCommands. Each RemoteCommand sends a message to the
buildslave asking it to run a single Command. All of these Commands are
defined in buildbot/slave/commands.py . There are a lot of master-side
BuildSteps (e.g. ShellCommand, Compile, Test, Trial, etc) that all wind up
using the same slave-side SlaveShellCommand, just with different arguments.

> Secondly, is it important for the two classes to be named the same
> thing?

No, not at all. The master-side BuildStep specifies which RemoteCommand it
wants to run with a string (e.g. ShellCommand uses the string "shell"); on
the slave-side, each RemoteCommand is registered using the same string. The
class names do not have to be the same, all that matters is that they both
use the same string.

> Thirdly, is it even possible to define a new VC system in master.cfg?

You can define the master-side portion of it. The buildslaves do not have
access to master.cfg, so if your VC system requires significant slave-side
support, then you'll have to make some code available on your buildslaves
too. That user manual section referenced above should describe enough of the
Python module-search-path mechanism to get you started.

All of the existing VC systems supported in Buildbot are implemented with
both master-side and slave-side components, using base classes to insure that
they all get the same level of support (the ability to check out arbitrary
revisions, to do 'export' builds, to do 'try' builds, etc). If you don't need
this level of support, it may be sufficient for you to manually do a 'cvs
checkout' (or equivalent) in your buildslave's directory once, and then have
a ShellCommand that does an update for each build later. That might save you
the trouble of implementing VC-support features that you don't really need.

hope that helps gets you started,
 -Brian