The first step of any build is typically to acquire the source code from which the build will be performed. There are several classes to handle this, one for each of the different source control system that Buildbot knows about. For a description of how Buildbot treats source control in general, see Version Control Systems.
All source checkout steps accept some common parameters to control how they get the sources and where they should be placed. The remaining per-VC-system parameters are mostly to specify where exactly the sources are coming from.
clobber, except that the 'cvs export' command is
used to create the working directory. This command removes all CVS
metadata files (the CVS/ directories) from the tree, which is
sometimes useful for creating source tarballs (to avoid including the
metadata in the tar file).
(delay, repeats) which means
that when a full VC checkout fails, it should be retried up to
repeats times, waiting delay seconds between attempts. If
you don't provide this, it defaults to
None, which means VC
operations should not be retried. This is provided to make life easier
for buildslaves which are stuck behind poor network connections.
repourl as well as for
applicable). Buildbot, now being aware of the repository name via the
ChangeSource step might in some cases not need the repository URL. There
are multiple way to pass it through to this step, corresponding to
the type of the parameter given to this step:
%s, then the repository
property from the Change will be substituted in place of the
%s. This is usefull when the ChangeSource step knows where the
repository resides locally, but doesn't know the scheme used to access
it. For instance,
ssh://server/%s makes sense if the repository
property is the local path of the repository.
Use of WithProperties with string, dict and callable is supported.
Note that this is quite similar to the mechanism used by the WebStatus
My habit as a developer is to do a
cvs update and
morning. Problems can occur, either because of bad code being checked in, or
by incomplete dependencies causing a partial rebuild to fail where a
complete from-scratch build might succeed. A quick Builder which emulates
this incremental-build behavior would use the
On the other hand, other kinds of dependency problems can cause a clean build to fail where a partial build might succeed. This frequently results from a link step that depends upon an object file that was removed from a later version of the tree: in the partial tree, the object file is still around (even though the Makefiles no longer know how to create it).
“official” builds (traceable builds performed from a known set of
source revisions) are always done as clean builds, to make sure it is
not influenced by any uncontrolled factors (like leftover files from a
previous build). A “full” Builder which behaves this way would want
to use the
Each VC system has a corresponding source checkout class: their arguments are described on the following pages.