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

Leibowitz, Michael michael.leibowitz at intel.com
Thu Jan 11 23:32:25 UTC 2007

I think I really do want to use the full functionality of a VC system on
the slaves.  I want to be able to have some slaves doing clobber
checkouts and some doing updates.

Is there an easy way to get the slave-side VC classes loaded besides
hacking the buildbot source on the slave?  Is there an equivalent to
master.cfg for slaves?  I can see how to make my classes in the
PYTHONPATH, but it seems that buildbot needs to execute the method
registerSlaveCommand to make my slave-side class available.  Is this

Thanks for your time.

Michael Leibowitz
Software Engineer, Channel Platform Solutions Group
Intel Corporation
michael.leibowitz at intel.com
+1 503 264 7621

>-----Original Message-----
>From: Brian Warner [mailto:warner-buildbot at lothar.com]
>Sent: Tuesday, January 09, 2007 1:22 AM
>To: Leibowitz, Michael
>Cc: buildbot-devel at lists.sourceforge.net
>Subject: Re: [Buildbot-devel] possible to add new VC to master.cfg?
>> 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
>> system.  It takes in two arguments, mode (co/up) and tag/branch.
>Have you considered just using a regular ShellCommand? If you're mostly
>updating to the most-recent version, then you may not need to use
>derived from the existing VC classes.
>> Since it is desirable to have the slaves using the upstream version
>> 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
>included by it. Take a look at
>(which is a subsection of the "Writing New BuildSteps chapter) for an
>of the different places you can put custom BuildStep classes and the
>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
>> the same (CVS(Source): and CVS(SourceBase):).  Firstly, I don't
>> understand what the purpose of these two different sets of classes
>Take a look at the files where those classes are defined. The first is
>master-side file (defined in buildbot/steps/source.py, which is used
>exclusively on the buildmaster side, and defines BuildStep classes
>be referenced from within the master.cfg file). The second is a
>file (defined in buildbot/slave/commands.py, which is used exclusively
>The master-side master.cfg file defines a Builder with a Factory with a
>of BuildSteps, including steps like CVS and ShellCommand. These
>may use one or more RemoteCommands. Each RemoteCommand sends a message
>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
>using the same slave-side SlaveShellCommand, just with different
>> 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
>wants to run with a string (e.g. ShellCommand uses the string "shell");
>the slave-side, each RemoteCommand is registered using the same string.
>class names do not have to be the same, all that matters is that they
>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
>access to master.cfg, so if your VC system requires significant
>support, then you'll have to make some code available on your
>too. That user manual section referenced above should describe enough
>Python module-search-path mechanism to get you started.
>All of the existing VC systems supported in Buildbot are implemented
>both master-side and slave-side components, using base classes to
>they all get the same level of support (the ability to check out
>revisions, to do 'export' builds, to do 'try' builds, etc). If you
>this level of support, it may be sufficient for you to manually do a
>checkout' (or equivalent) in your buildslave's directory once, and then
>a ShellCommand that does an update for each build later. That might
>the trouble of implementing VC-support features that you don't really
>hope that helps gets you started,
> -Brian

More information about the devel mailing list