This lets a developer to ask the question “What would happen if I committed this patch right now?”. It runs the unit test suite (across multiple build platforms) on the developer's current code, allowing them to make sure they will not break the tree when they finally commit their changes.
The buildbot try command is meant to be run from within a developer's local tree, and starts by figuring out the base revision of that tree (what revision was current the last time the tree was updated), and a patch that can be applied to that revision of the tree to make it match the developer's copy. This (revision, patch) pair is then sent to the buildmaster, which runs a build with that SourceStamp. If you want, the tool will emit status messages as the builds run, and will not terminate until the first failure has been detected (or the last success).
There is an alternate form which accepts a pre-made patch file (typically the output of a command like 'svn diff'). This “–diff” form does not require a local tree to run from. See See try, concerning the “–diff” command option.
For this command to work, several pieces must be in place: the See Try Schedulers, as well as some client-side configuration.
The try command needs to be told how to connect to the
try scheduler, and must know which of the authentication
approaches described above is in use by the buildmaster. You specify
the approach by using --connect=ssh or --connect=pb
(or try_connect = 'ssh' or try_connect = 'pb' in
.buildbot/options).
For the PB approach, the command must be given a --master
argument (in the form HOST:PORT) that points to TCP port that you picked
in the Try_Userpass scheduler. It also takes a
--username and --passwd pair of arguments that match
one of the entries in the buildmaster's userpass list. These
arguments can also be provided as try_master,
try_username, and try_password entries in the
.buildbot/options file.
For the SSH approach, the command must be given --host and
--username to get to the buildmaster host. It must also be
given --jobdir, which points to the inlet directory configured
above. The jobdir can be relative to the user's home directory, but most
of the time you will use an explicit path like
~buildbot/project/jobdir. These arguments can be provided in
.buildbot/options as try_host, try_username, and
try_jobdir.
In addition, the SSH approach needs to connect to a PBListener status
port, so it can retrieve and report the results of the build (the PB
approach uses the existing connection to retrieve status information,
so this step is not necessary). This requires a --masterstatus
argument, or a try_masterstatus entry in .buildbot/options,
in the form of a HOSTNAME:PORT string.
The following command line arguments are deprecated, but retained for backward compatibility:
Likewise, the following .buildbot/options file entries are deprecated, but retained for backward compatibility:
try_dir is replaced by try_jobdir
masterstatus is replaced by try_masterstatus
A trial build is performed on multiple Builders at the same time, and
the developer gets to choose which Builders are used (limited to a set
selected by the buildmaster admin with the TryScheduler's
builderNames= argument). The set you choose will depend upon
what your goals are: if you are concerned about cross-platform
compatibility, you should use multiple Builders, one from each
platform of interest. You might use just one builder if that platform
has libraries or other facilities that allow better test coverage than
what you can accomplish on your own machine, or faster test runs.
The set of Builders to use can be specified with multiple
--builder arguments on the command line. It can also be
specified with a single try_builders option in
.buildbot/options that uses a list of strings to specify all
the Builder names:
try_builders = ["full-OSX", "full-win32", "full-linux"]
If you are using the PB approach, you can get the names of the builders
that are configured for the try scheduler using the get-builder-names
argument:
buildbot try --get-builder-names --connect=pb --master=... --username=... --passwd=...
The try command also needs to know how to take the
developer's current tree and extract the (revision, patch)
source-stamp pair. Each VC system uses a different process, so you
start by telling the try command which VC system you are
using, with an argument like --vc=cvs or --vc=git.
This can also be provided as try_vc in
.buildbot/options.
The following names are recognized: bzr cvs
darcs git hg mtn p4 svn
Some VC systems (notably CVS and SVN) track each directory
more-or-less independently, which means the try command
needs to move up to the top of the project tree before it will be able
to construct a proper full-tree patch. To accomplish this, the
try command will crawl up through the parent directories
until it finds a marker file. The default name for this marker file is
.buildbot-top, so when you are using CVS or SVN you should
touch .buildbot-top from the top of your tree before running
buildbot try. Alternatively, you can use a filename like
ChangeLog or README, since many projects put one of
these files in their top-most directory (and nowhere else). To set
this filename, use --topfile=ChangeLog, or set it in the
options file with try_topfile = 'ChangeLog'.
You can also manually set the top of the tree with
--topdir=~/trees/mytree, or try_topdir =
'~/trees/mytree'. If you use try_topdir, in a
.buildbot/options file, you will need a separate options file
for each tree you use, so it may be more convenient to use the
try_topfile approach instead.
Other VC systems which work on full projects instead of individual directories (darcs, mercurial, git, monotone) do not require try to know the top directory, so the --topfile and --topdir arguments will be ignored.
If the try command cannot find the top directory, it will abort with an error message.
The following command line arguments are deprecated, but retained for backward compatibility:
Some VC systems record the branch information in a way that “try” can locate it. For the others, if you are using something other than the default branch, you will have to tell the buildbot which branch your tree is using. You can do this with either the --branch argument, or a try_branch entry in the .buildbot/options file.
Each VC system has a separate approach for determining the tree's base revision and computing a patch.
CVS-D time specification, uses it as the base
revision, and computes the diff between the upstream tree as of that
point in time versus the current contents. This works, more or less,
but requires that the local clock be in reasonably good sync with the
repository.
SVNsvn status -u to find the latest
repository revision number (emitted on the last line in the “Status
against revision: NN” message). It then performs an svn diff
-rNN to find out how your tree differs from the repository version,
and sends the resulting patch to the buildmaster. If your tree is not
up to date, this will result in the “try” tree being created with
the latest revision, then backwards patches applied to bring it
“back” to the version you actually checked out (plus your actual
code changes), but this will still result in the correct tree being
used for the build.
bzrbzr revision-info to find the base revision,
then a bzr diff -r$base.. to obtain the patch.
Mercurialhg identify --debug emits the full revision id (as opposed to
the common 12-char truncated) which is a SHA1 hash of the current
revision's contents. This is used as the base revision.
hg diff then provides the patch relative to that
revision. For try to work, your working directory must only
have patches that are available from the same remotely-available
repository that the build process' source.Mercurial will use.
Perforcep4 changes -m1 ... to determine the latest
changelist and implicitly assumes that the local tree is synched to this
revision. This is followed by a p4 diff -du to obtain the patch.
A p4 patch differs sligtly from a normal diff. It contains full depot
paths and must be converted to paths relative to the branch top. To convert
the following restriction is imposed. The p4base (see see P4Source)
is assumed to be //depot
Darcsdarcs changes --context to find the list
of all patches back to and including the last tag that was made. This text
file (plus the location of a repository that contains all these
patches) is sufficient to re-create the tree. Therefore the contents
of this “context” file are the revision stamp for a
Darcs-controlled source tree. It then does a darcs diff
-u to compute the patch relative to that revision.
Gitgit branch -v lists all the branches available in the local
repository along with the revision ID it points to and a short summary
of the last commit. The line containing the currently checked out
branch begins with '* ' (star and space) while all the others start
with ' ' (two spaces). try scans for this line and extracts
the branch name and revision from it. Then it generates a diff against
the base revision.
Monotonemtn automate get_base_revision_id emits the full revision id
which is a SHA1 hash of the current revision's contents. This is used as
the base revision.
mtn diff then provides the patch relative to that revision. For
try to work, your working directory must only have patches
that are available from the same remotely-available repository that the
build process' source.Monotone will use.
You can provide the --who=dev to designate who is running the
try build. This will add the dev to the Reason field on the try
build's status web page. You can also set try_who = dev in the
.buildbot/options file. Note that --who=dev will not
work on version 0.8.3 or earlier masters.
If you provide the --wait option (or try_wait = True
in .buildbot/options), the buildbot try command will
wait until your changes have either been proven good or bad before
exiting. Unless you use the --quiet option (or
try_quiet=True), it will emit a progress message every 60
seconds until the builds have completed.
Sometimes you might have a patch from someone else that you want to submit to the buildbot. For example, a user may have created a patch to fix some specific bug and sent it to you by email. You've inspected the patch and suspect that it might do the job (and have at least confirmed that it doesn't do anything evil). Now you want to test it out.
One approach would be to check out a new local tree, apply the patch, run your local tests, then use “buildbot try” to run the tests on other platforms. An alternate approach is to use the buildbot try --diff form to have the buildbot test the patch without using a local tree.
This form takes a --diff argument which points to a file that contains the patch you want to apply. By default this patch will be applied to the TRUNK revision, but if you give the optional --baserev argument, a tree of the given revision will be used as a starting point instead of TRUNK.
You can also use buildbot try --diff=- to read the patch from stdin.
Each patch has a “patchlevel” associated with it. This indicates the number of slashes (and preceding pathnames) that should be stripped before applying the diff. This exactly corresponds to the -p or --strip argument to the patch utility. By default buildbot try --diff uses a patchlevel of 0, but you can override this with the -p argument.
When you use --diff, you do not need to use any of the other options that relate to a local tree, specifically --vc, --topfile, or --topdir. These options will be ignored. Of course you must still specify how to get to the buildmaster (with --connect, --host, etc).