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.
repourlas well as for
baseURL(when 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/%smakes 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.