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.
mode
update
.
update
copy
clobber
export
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).
workdir
alwaysUseLatest
retry
(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.
repository
repourl
as well as for baseURL
(when
aplicable). 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, those correspond to
the type of the parameter given to this step:
None
string
format string
%s
, then this the
repository property from the Change will be place in place of the
%s
. This is usefull when the ChangeSource step knows where the
repository resides locally, but don't know the scheme used to access
it. For instance ssh://server/%s
makes sense if the the
repository property is the local path of the repository.
dict
callable
Note that this is quite similar to the mechanism used by the WebStatus
for the changecommentlink
, projects
or repositories
parameter.
My habit as a developer is to do a cvs update
and make
each
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 mode='update'
setting.
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 mode='clobber'
setting.
Each VC system has a corresponding source checkout class: their arguments are described on the following pages.