diff options
Diffstat (limited to 'buildbot/docs/buildbot.info-2')
| -rw-r--r-- | buildbot/docs/buildbot.info-2 | 1654 |
1 files changed, 1654 insertions, 0 deletions
diff --git a/buildbot/docs/buildbot.info-2 b/buildbot/docs/buildbot.info-2 new file mode 100644 index 0000000..bb7089a --- /dev/null +++ b/buildbot/docs/buildbot.info-2 @@ -0,0 +1,1654 @@ +This is buildbot.info, produced by makeinfo version 4.11 from +buildbot.texinfo. + +This is the BuildBot manual. + + Copyright (C) 2005,2006 Brian Warner + + Copying and distribution of this file, with or without +modification, are permitted in any medium without royalty provided +the copyright notice and this notice are preserved. + + +File: buildbot.info, Node: Buildbot Web Resources, Next: XMLRPC server, Prev: WebStatus Configuration Parameters, Up: WebStatus + +7.1.2 Buildbot Web Resources +---------------------------- + +Certain URLs are "magic", and the pages they serve are created by +code in various classes in the `buildbot.status.web' package instead +of being read from disk. The most common way to access these pages is +for the buildmaster admin to write or modify the `index.html' page to +contain links to them. Of course other project web pages can contain +links to these buildbot pages as well. + + Many pages can be modified by adding query arguments to the URL. +For example, a page which shows the results of the most recent build +normally does this for all builders at once. But by appending +"?builder=i386" to the end of the URL, the page will show only the +results for the "i386" builder. When used in this way, you can add +multiple "builder=" arguments to see multiple builders. Remembering +that URL query arguments are separated _from each other_ with +ampersands, a URL that ends in "?builder=i386&builder=ppc" would show +builds for just those two Builders. + + The `branch=' query argument can be used on some pages. This +filters the information displayed by that page down to only the builds +or changes which involved the given branch. Use `branch=trunk' to +reference the trunk: if you aren't intentionally using branches, +you're probably using trunk. Multiple `branch=' arguments can be used +to examine multiple branches at once (so appending +`?branch=foo&branch=bar' to the URL will show builds involving either +branch). No `branch=' arguments means to show builds and changes for +all branches. + + Some pages may include the Builder name or the build number in the +main part of the URL itself. For example, a page that describes Build +#7 of the "i386" builder would live at `/builders/i386/builds/7'. + + The table below lists all of the internal pages and the URLs that +can be used to access them. + + NOTE: of the pages described here, `/slave_status_timeline' and +`/last_build' have not yet been implemented, and `/xmlrpc' has only a +few methods so far. Future releases will improve this. + +`/waterfall' + This provides a chronologically-oriented display of the activity + of all builders. It is the same display used by the Waterfall + display. + + By adding one or more "builder=" query arguments, the Waterfall + is restricted to only showing information about the given + Builders. By adding one or more "branch=" query arguments, the + display is restricted to showing information about the given + branches. In addition, adding one or more "category=" query + arguments to the URL will limit the display to Builders that + were defined with one of the given categories. + + A 'show_events=true' query argument causes the display to include + non-Build events, like slaves attaching and detaching, as well as + reconfiguration events. 'show_events=false' hides these events. + The default is to show them. + + The `last_time=', `first_time=', and `show_time=' arguments will + control what interval of time is displayed. The default is to + show the latest events, but these can be used to look at earlier + periods in history. The `num_events=' argument also provides a + limit on the size of the displayed page. + + The Waterfall has references to resources many of the other + portions of the URL space: `/builders' for access to individual + builds, `/changes' for access to information about source code + changes, etc. + +`/rss' + This provides a rss feed summarizing all failed builds. The same + query-arguments used by 'waterfall' can be added to filter the + feed output. + +`/atom' + This provides an atom feed summarizing all failed builds. The + same query-arguments used by 'waterfall' can be added to filter + the feed output. + +`/builders/$BUILDERNAME' + This describes the given Builder, and provides buttons to force + a build. + +`/builders/$BUILDERNAME/builds/$BUILDNUM' + This describes a specific Build. + +`/builders/$BUILDERNAME/builds/$BUILDNUM/steps/$STEPNAME' + This describes a specific BuildStep. + +`/builders/$BUILDERNAME/builds/$BUILDNUM/steps/$STEPNAME/logs/$LOGNAME' + This provides an HTML representation of a specific logfile. + +`/builders/$BUILDERNAME/builds/$BUILDNUM/steps/$STEPNAME/logs/$LOGNAME/text' + This returns the logfile as plain text, without any HTML coloring + markup. It also removes the "headers", which are the lines that + describe what command was run and what the environment variable + settings were like. This maybe be useful for saving to disk and + feeding to tools like 'grep'. + +`/changes' + This provides a brief description of the ChangeSource in use + (*note Change Sources::). + +`/changes/NN' + This shows detailed information about the numbered Change: who + was the author, what files were changed, what revision number + was represented, etc. + +`/buildslaves' + This summarizes each BuildSlave, including which Builders are + configured to use it, whether the buildslave is currently + connected or not, and host information retrieved from the + buildslave itself. + +`/one_line_per_build' + This page shows one line of text for each build, merging + information from all Builders(1). Each line specifies the name + of the Builder, the number of the Build, what revision it used, + and a summary of the results. Successful builds are in green, + while failing builds are in red. The date and time of the build + are added to the right-hand edge of the line. The lines are + ordered by build finish timestamp. + + One or more `builder=' or `branch=' arguments can be used to + restrict the list. In addition, a `numbuilds=' argument will + control how many lines are displayed (20 by default). + +`/one_box_per_builder' + This page shows a small table, with one box for each Builder, + containing the results of the most recent Build. It does not + show the individual steps, or the current status. This is a + simple summary of buildbot status: if this page is green, then + all tests are passing. + + As with `/one_line_per_build', this page will also honor + `builder=' and `branch=' arguments. + +`/about' + This page gives a brief summary of the Buildbot itself: software + version, versions of some libraries that the Buildbot depends + upon, etc. It also contains a link to the buildbot.net home page. + +`/slave_status_timeline' + (note: this page has not yet been implemented) + + This provides a chronological display of configuration and + operational events: master startup/shutdown, slave + connect/disconnect, and config-file changes. When a config-file + reload is abandoned because of an error in the config file, the + error is displayed on this page. + + This page does not show any builds. + +`/last_build/$BUILDERNAME/status.png' + This returns a PNG image that describes the results of the most + recent build, which can be referenced in an IMG tag by other + pages, perhaps from a completely different site. Use it as you + would a webcounter. + + + There are also a set of web-status resources that are intended for +use by other programs, rather than humans. + +`/xmlrpc' + This runs an XML-RPC server which can be used to query status + information about various builds. See *note XMLRPC server:: for + more details. + + + ---------- Footnotes ---------- + + (1) Apparently this is the same way http://buildd.debian.org +displays build status + + +File: buildbot.info, Node: XMLRPC server, Next: HTML Waterfall, Prev: Buildbot Web Resources, Up: WebStatus + +7.1.3 XMLRPC server +------------------- + +When using WebStatus, the buildbot runs an XML-RPC server at +`/xmlrpc' that can be used by other programs to query build status. +The following table lists the methods that can be invoked using this +interface. + +`getAllBuildsInInterval(start, stop)' + Return a list of builds that have completed after the 'start' + timestamp and before the 'stop' timestamp. This looks at all + Builders. + + The timestamps are integers, interpreted as standard unix + timestamps (seconds since epoch). + + Each Build is returned as a tuple in the form: `(buildername, + buildnumber, build_end, branchname, revision, results, text)' + + The buildnumber is an integer. 'build_end' is an integer (seconds + since epoch) specifying when the build finished. + + The branchname is a string, which may be an empty string to + indicate None (i.e. the default branch). The revision is a + string whose meaning is specific to the VC system in use, and + comes from the 'got_revision' build property. The results are + expressed as a string, one of ('success', 'warnings', 'failure', + 'exception'). The text is a list of short strings that ought to + be joined by spaces and include slightly more data about the + results of the build. + +`getBuild(builder_name, build_number)' + Return information about a specific build. + + This returns a dictionary (aka "struct" in XMLRPC terms) with + complete information about the build. It does not include the + contents of the log files, but it has just about everything else. + + + +File: buildbot.info, Node: HTML Waterfall, Prev: XMLRPC server, Up: WebStatus + +7.1.4 HTML Waterfall +-------------------- + +The `Waterfall' status target, deprecated as of 0.7.6, is a subset of +the regular `WebStatus' resource (*note WebStatus::). This section +(and the `Waterfall' class itself) will be removed from a future +release. + + from buildbot.status import html + w = html.WebStatus(http_port=8080) + c['status'].append(w) + + +File: buildbot.info, Node: MailNotifier, Next: IRC Bot, Prev: WebStatus, Up: Status Delivery + +7.2 MailNotifier +================ + +The buildbot can also send email when builds finish. The most common +use of this is to tell developers when their change has caused the +build to fail. It is also quite common to send a message to a mailing +list (usually named "builds" or similar) about every build. + + The `MailNotifier' status target is used to accomplish this. You +configure it by specifying who mail should be sent to, under what +circumstances mail should be sent, and how to deliver the mail. It can +be configured to only send out mail for certain builders, and only +send messages when the build fails, or when the builder transitions +from success to failure. It can also be configured to include various +build logs in each message. + + By default, the message will be sent to the Interested Users list +(*note Doing Things With Users::), which includes all developers who +made changes in the build. You can add additional recipients with the +extraRecipients argument. + + Each MailNotifier sends mail to a single set of recipients. To send +different kinds of mail to different recipients, use multiple +MailNotifiers. + + The following simple example will send an email upon the +completion of each build, to just those developers whose Changes were +included in the build. The email contains a description of the Build, +its results, and URLs where more information can be obtained. + + from buildbot.status.mail import MailNotifier + mn = MailNotifier(fromaddr="buildbot@example.org", lookup="example.org") + c['status'].append(mn) + + To get a simple one-message-per-build (say, for a mailing list), +use the following form instead. This form does not send mail to +individual developers (and thus does not need the `lookup=' argument, +explained below), instead it only ever sends mail to the "extra +recipients" named in the arguments: + + mn = MailNotifier(fromaddr="buildbot@example.org", + sendToInterestedUsers=False, + extraRecipients=['listaddr@example.org']) + + In some cases it is desirable to have different information then +what is provided in a standard MailNotifier message. For this purpose +MailNotifier provides the argument customMesg (a function) which +allows for the creation of messages with unique content. + + For example it can be useful to display the last few lines of a +log file and recent changes when a builder fails: + + def message(attrs): + logLines = 10 + text = list() + text.append("STATUS: %s" % attrs['result'].title()) + text.append("") + text.extend([c.asText() for c in attrs['changes']]) + text.append("") + name, url, lines = attrs['logs'][-1] + text.append("Last %d lines of '%s':" % (logLines, name)) + text.extend(["\t%s\n" % line for line in lines[len(lines)-logLines:]]) + text.append("") + text.append("-buildbot") + return ("\n".join(text), 'plain') + + mn = MailNotifier(fromaddr="buildbot@example.org", + sendToInterestedUsers=False, + mode='problem', + extraRecipients=['listaddr@example.org'], + customMesg=message) + + A customMesg function takes a single dict argument (see below) and +returns a tuple of strings. The first string is the complete text of +the message and the second is the message type ('plain' or 'html'). +The 'html' type should be used when generating an HTML message: + + def message(attrs): + logLines = 10 + text = list() + text.append('<h4>Build status %s.</h4>' % (attrs['result'].title())) + if attrs['changes']: + text.append('<h4>Recent Changes:</h4>') + text.extend([c.asHTML() for c in attrs['changes']]) + name, url, lines = attrs['logs'][-1] + text.append('<h4>Last %d lines of "%s":</h4>' % (logLines, name)) + text.append('<p>') + text.append('<br>'.join([line for line in lines[len(lines)-logLines:]])) + text.append('</p>') + text.append('<br><br>') + text.append('Full log at: %s' % url) + text.append('<br><br>') + text.append('<b>-buildbot</b>') + return ('\n'.join(text), 'html') + +MailNotifier arguments +====================== + +`fromaddr' + The email address to be used in the 'From' header. + +`sendToInterestedUsers' + (boolean). If True (the default), send mail to all of the + Interested Users. If False, only send mail to the + extraRecipients list. + +`extraRecipients' + (tuple of strings). A list of email addresses to which messages + should be sent (in addition to the InterestedUsers list, which + includes any developers who made Changes that went into this + build). It is a good idea to create a small mailing list and + deliver to that, then let subscribers come and go as they please. + +`subject' + (string). A string to be used as the subject line of the message. + `%(builder)s' will be replaced with the name of the builder which + provoked the message. + +`mode' + (string). Default to 'all'. One of: + `all' + Send mail about all builds, bothpassing and failing + + `failing' + Only send mail about builds which fail + + `problem' + Only send mail about a build which failed when the previous + build has passed. If your builds usually pass, then this + will only send mail when a problem occurs. + +`builders' + (list of strings). A list of builder names for which mail should + be sent. Defaults to None (send mail for all builds). Use either + builders or categories, but not both. + +`categories' + (list of strings). A list of category names to serve status + information for. Defaults to None (all categories). Use either + builders or categories, but not both. + +`addLogs' + (boolean). If True, include all build logs as attachments to the + messages. These can be quite large. This can also be set to a + list of log names, to send a subset of the logs. Defaults to + False. + +`relayhost' + (string). The host to which the outbound SMTP connection should + be made. Defaults to 'localhost' + +`lookup' + (implementor of `IEmailLookup'). Object which provides + IEmailLookup, which is responsible for mapping User names (which + come from the VC system) into valid email addresses. If not + provided, the notifier will only be able to send mail to the + addresses in the extraRecipients list. Most of the time you can + use a simple Domain instance. As a shortcut, you can pass as + string: this will be treated as if you had provided Domain(str). + For example, lookup='twistedmatrix.com' will allow mail to be + sent to all developers whose SVN usernames match their + twistedmatrix.com account names. See buildbot/status/mail.py for + more details. + +`customMesg' + This is a optional function that can be used to generate a + custom mail message. The customMesg function takes a single dict + and must return a tuple containing the message text and type + ('html' or 'plain'). Below is a list of availale keys in the + dict passed to customMesg: + + `builderName' + (str) Name of the builder that generated this event. + + `projectName' + (str) Name of the project. + + `mode' + (str) Mode set in MailNotifier. (failing, passing, problem). + + `result' + (str) Builder result as a string. 'success', 'warnings', + 'failure', 'skipped', or 'exception' + + `buildURL' + (str) URL to build page. + + `buildbotURL' + (str) URL to buildbot main page. + + `buildText' + (str) Build text from build.getText(). + + `slavename' + (str) Slavename. + + `reason' + (str) Build reason from build.getReason(). + + `responsibleUsers' + (List of str) List of responsible users. + + `branch' + (str) Name of branch used. If no SourceStamp exists branch + is an empty string. + + `revision' + (str) Name of revision used. If no SourceStamp exists + revision is an empty string. + + `patch' + (str) Name of patch used. If no SourceStamp exists patch is + an empty string. + + `changes' + (list of objs) List of change objects from SourceStamp. A + change object has the following useful information: + `who' + (str) who made this change + + `revision' + (str) what VC revision is this change + + `branch' + (str) on what branch did this change occur + + `when' + (str) when did this change occur + + `files' + (list of str) what files were affected in this change + + `comments' + (str) comments reguarding the change. + The functions asText and asHTML return a list of strings + with the above information formatted. + + `logs' + (List of Tuples) List of tuples where each tuple contains + the log name, log url, and log contents as a list of + strings. + + +File: buildbot.info, Node: IRC Bot, Next: PBListener, Prev: MailNotifier, Up: Status Delivery + +7.3 IRC Bot +=========== + +The `buildbot.status.words.IRC' status target creates an IRC bot +which will attach to certain channels and be available for status +queries. It can also be asked to announce builds as they occur, or be +told to shut up. + + from buildbot.status import words + irc = words.IRC("irc.example.org", "botnickname", + channels=["channel1", "channel2"], + password="mysecretpassword", + notify_events={ + 'exception': 1, + 'successToFailure': 1, + 'failureToSuccess': 1, + }) + c['status'].append(irc) + + Take a look at the docstring for `words.IRC' for more details on +configuring this service. The `password' argument, if provided, will +be sent to Nickserv to claim the nickname: some IRC servers will not +allow clients to send private messages until they have logged in with +a password. + + To use the service, you address messages at the buildbot, either +normally (`botnickname: status') or with private messages (`/msg +botnickname status'). The buildbot will respond in kind. + + Some of the commands currently available: + +`list builders' + Emit a list of all configured builders + +`status BUILDER' + Announce the status of a specific Builder: what it is doing + right now. + +`status all' + Announce the status of all Builders + +`watch BUILDER' + If the given Builder is currently running, wait until the Build + is finished and then announce the results. + +`last BUILDER' + Return the results of the last build to run on the given Builder. + +`join CHANNEL' + Join the given IRC channel + +`leave CHANNEL' + Leave the given IRC channel + +`notify on|off|list EVENT' + Report events relating to builds. If the command is issued as a + private message, then the report will be sent back as a private + message to the user who issued the command. Otherwise, the + report will be sent to the channel. Available events to be + notified are: + + `started' + A build has started + + `finished' + A build has finished + + `success' + A build finished successfully + + `failed' + A build failed + + `exception' + A build generated and exception + + `xToY' + The previous build was x, but this one is Y, where x and Y + are each one of success, warnings, failure, exception + (except Y is capitalized). For example: successToFailure + will notify if the previous build was successful, but this + one failed + +`help COMMAND' + Describe a command. Use `help commands' to get a list of known + commands. + +`source' + Announce the URL of the Buildbot's home page. + +`version' + Announce the version of this Buildbot. + + Additionally, the config file may specify default notification +options as shown in the example earlier. + + If the `allowForce=True' option was used, some addtional commands +will be available: + +`force build BUILDER REASON' + Tell the given Builder to start a build of the latest code. The + user requesting the build and REASON are recorded in the Build + status. The buildbot will announce the build's status when it + finishes. + +`stop build BUILDER REASON' + Terminate any running build in the given Builder. REASON will be + added to the build status to explain why it was stopped. You + might use this if you committed a bug, corrected it right away, + and don't want to wait for the first build (which is destined to + fail) to complete before starting the second (hopefully fixed) + build. + + +File: buildbot.info, Node: PBListener, Next: Writing New Status Plugins, Prev: IRC Bot, Up: Status Delivery + +7.4 PBListener +============== + + import buildbot.status.client + pbl = buildbot.status.client.PBListener(port=int, user=str, + passwd=str) + c['status'].append(pbl) + + This sets up a PB listener on the given TCP port, to which a +PB-based status client can connect and retrieve status information. +`buildbot statusgui' (*note statusgui::) is an example of such a +status client. The `port' argument can also be a strports +specification string. + + +File: buildbot.info, Node: Writing New Status Plugins, Prev: PBListener, Up: Status Delivery + +7.5 Writing New Status Plugins +============================== + +TODO: this needs a lot more examples + + Each status plugin is an object which provides the +`twisted.application.service.IService' interface, which creates a +tree of Services with the buildmaster at the top [not strictly true]. +The status plugins are all children of an object which implements +`buildbot.interfaces.IStatus', the main status object. From this +object, the plugin can retrieve anything it wants about current and +past builds. It can also subscribe to hear about new and upcoming +builds. + + Status plugins which only react to human queries (like the +Waterfall display) never need to subscribe to anything: they are idle +until someone asks a question, then wake up and extract the +information they need to answer it, then they go back to sleep. +Plugins which need to act spontaneously when builds complete (like +the MailNotifier plugin) need to subscribe to hear about new builds. + + If the status plugin needs to run network services (like the HTTP +server used by the Waterfall plugin), they can be attached as Service +children of the plugin itself, using the `IServiceCollection' +interface. + + +File: buildbot.info, Node: Command-line tool, Next: Resources, Prev: Status Delivery, Up: Top + +8 Command-line tool +******************* + +The `buildbot' command-line tool can be used to start or stop a +buildmaster or buildbot, and to interact with a running buildmaster. +Some of its subcommands are intended for buildmaster admins, while +some are for developers who are editing the code that the buildbot is +monitoring. + +* Menu: + +* Administrator Tools:: +* Developer Tools:: +* Other Tools:: +* .buildbot config directory:: + + +File: buildbot.info, Node: Administrator Tools, Next: Developer Tools, Prev: Command-line tool, Up: Command-line tool + +8.1 Administrator Tools +======================= + +The following `buildbot' sub-commands are intended for buildmaster +administrators: + +create-master +============= + +This creates a new directory and populates it with files that allow it +to be used as a buildmaster's base directory. + + buildbot create-master BASEDIR + +create-slave +============ + +This creates a new directory and populates it with files that let it +be used as a buildslave's base directory. You must provide several +arguments, which are used to create the initial `buildbot.tac' file. + + buildbot create-slave BASEDIR MASTERHOST:PORT SLAVENAME PASSWORD + +start +===== + +This starts a buildmaster or buildslave which was already created in +the given base directory. The daemon is launched in the background, +with events logged to a file named `twistd.log'. + + buildbot start BASEDIR + +stop +==== + +This terminates the daemon (either buildmaster or buildslave) running +in the given directory. + + buildbot stop BASEDIR + +sighup +====== + +This sends a SIGHUP to the buildmaster running in the given directory, +which causes it to re-read its `master.cfg' file. + + buildbot sighup BASEDIR + + +File: buildbot.info, Node: Developer Tools, Next: Other Tools, Prev: Administrator Tools, Up: Command-line tool + +8.2 Developer Tools +=================== + +These tools are provided for use by the developers who are working on +the code that the buildbot is monitoring. + +* Menu: + +* statuslog:: +* statusgui:: +* try:: + + +File: buildbot.info, Node: statuslog, Next: statusgui, Prev: Developer Tools, Up: Developer Tools + +8.2.1 statuslog +--------------- + + buildbot statuslog --master MASTERHOST:PORT + + This command starts a simple text-based status client, one which +just prints out a new line each time an event occurs on the +buildmaster. + + The `--master' option provides the location of the +`buildbot.status.client.PBListener' status port, used to deliver +build information to realtime status clients. The option is always in +the form of a string, with hostname and port number separated by a +colon (`HOSTNAME:PORTNUM'). Note that this port is _not_ the same as +the slaveport (although a future version may allow the same port +number to be used for both purposes). If you get an error message to +the effect of "Failure: twisted.cred.error.UnauthorizedLogin:", this +may indicate that you are connecting to the slaveport rather than a +`PBListener' port. + + The `--master' option can also be provided by the `masterstatus' +name in `.buildbot/options' (*note .buildbot config directory::). + + +File: buildbot.info, Node: statusgui, Next: try, Prev: statuslog, Up: Developer Tools + +8.2.2 statusgui +--------------- + +If you have set up a PBListener (*note PBListener::), you will be able +to monitor your Buildbot using a simple Gtk+ application invoked with +the `buildbot statusgui' command: + + buildbot statusgui --master MASTERHOST:PORT + + This command starts a simple Gtk+-based status client, which +contains a few boxes for each Builder that change color as events +occur. It uses the same `--master' argument as the `buildbot +statuslog' command (*note statuslog::). + + +File: buildbot.info, Node: try, Prev: statusgui, Up: Developer Tools + +8.2.3 try +--------- + +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 *Note try +--diff::. + + For this command to work, several pieces must be in place: + +TryScheduler +============ + +The buildmaster must have a `scheduler.Try' instance in the config +file's `c['schedulers']' list. This lets the administrator control +who may initiate these "trial" builds, which branches are eligible +for trial builds, and which Builders should be used for them. + + The `TryScheduler' has various means to accept build requests: all +of them enforce more security than the usual buildmaster ports do. +Any source code being built can be used to compromise the buildslave +accounts, but in general that code must be checked out from the VC +repository first, so only people with commit privileges can get +control of the buildslaves. The usual force-build control channels can +waste buildslave time but do not allow arbitrary commands to be +executed by people who don't have those commit privileges. However, +the source code patch that is provided with the trial build does not +have to go through the VC system first, so it is important to make +sure these builds cannot be abused by a non-committer to acquire as +much control over the buildslaves as a committer has. Ideally, only +developers who have commit access to the VC repository would be able +to start trial builds, but unfortunately the buildmaster does not, in +general, have access to VC system's user list. + + As a result, the `TryScheduler' requires a bit more configuration. +There are currently two ways to set this up: + +*jobdir (ssh)* + This approach creates a command queue directory, called the + "jobdir", in the buildmaster's working directory. The buildmaster + admin sets the ownership and permissions of this directory to + only grant write access to the desired set of developers, all of + whom must have accounts on the machine. The `buildbot try' + command creates a special file containing the source stamp + information and drops it in the jobdir, just like a standard + maildir. When the buildmaster notices the new file, it unpacks + the information inside and starts the builds. + + The config file entries used by 'buildbot try' either specify a + local queuedir (for which write and mv are used) or a remote one + (using scp and ssh). + + The advantage of this scheme is that it is quite secure, the + disadvantage is that it requires fiddling outside the buildmaster + config (to set the permissions on the jobdir correctly). If the + buildmaster machine happens to also house the VC repository, + then it can be fairly easy to keep the VC userlist in sync with + the trial-build userlist. If they are on different machines, + this will be much more of a hassle. It may also involve granting + developer accounts on a machine that would not otherwise require + them. + + To implement this, the buildslave invokes 'ssh -l username host + buildbot tryserver ARGS', passing the patch contents over stdin. + The arguments must include the inlet directory and the revision + information. + +*user+password (PB)* + In this approach, each developer gets a username/password pair, + which are all listed in the buildmaster's configuration file. + When the developer runs `buildbot try', their machine connects + to the buildmaster via PB and authenticates themselves using + that username and password, then sends a PB command to start the + trial build. + + The advantage of this scheme is that the entire configuration is + performed inside the buildmaster's config file. The + disadvantages are that it is less secure (while the "cred" + authentication system does not expose the password in plaintext + over the wire, it does not offer most of the other security + properties that SSH does). In addition, the buildmaster admin is + responsible for maintaining the username/password list, adding + and deleting entries as developers come and go. + + + For example, to set up the "jobdir" style of trial build, using a +command queue directory of `MASTERDIR/jobdir' (and assuming that all +your project developers were members of the `developers' unix group), +you would first create that directory (with `mkdir MASTERDIR/jobdir +MASTERDIR/jobdir/new MASTERDIR/jobdir/cur MASTERDIR/jobdir/tmp; chgrp +developers MASTERDIR/jobdir MASTERDIR/jobdir/*; chmod g+rwx,o-rwx +MASTERDIR/jobdir MASTERDIR/jobdir/*'), and then use the following +scheduler in the buildmaster's config file: + + from buildbot.scheduler import Try_Jobdir + s = Try_Jobdir("try1", ["full-linux", "full-netbsd", "full-OSX"], + jobdir="jobdir") + c['schedulers'] = [s] + + Note that you must create the jobdir before telling the +buildmaster to use this configuration, otherwise you will get an +error. Also remember that the buildmaster must be able to read and +write to the jobdir as well. Be sure to watch the `twistd.log' file +(*note Logfiles::) as you start using the jobdir, to make sure the +buildmaster is happy with it. + + To use the username/password form of authentication, create a +`Try_Userpass' instance instead. It takes the same `builderNames' +argument as the `Try_Jobdir' form, but accepts an addtional `port' +argument (to specify the TCP port to listen on) and a `userpass' list +of username/password pairs to accept. Remember to use good passwords +for this: the security of the buildslave accounts depends upon it: + + from buildbot.scheduler import Try_Userpass + s = Try_Userpass("try2", ["full-linux", "full-netbsd", "full-OSX"], + port=8031, userpass=[("alice","pw1"), ("bob", "pw2")] ) + c['schedulers'] = [s] + + Like most places in the buildbot, the `port' argument takes a +strports specification. See `twisted.application.strports' for +details. + +locating the master +=================== + +The `try' command needs to be told how to connect to the +`TryScheduler', 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 `--tryhost', +`--username', and optionally `--password' (TODO: really?) to get to +the buildmaster host. It must also be given `--trydir', which points +to the inlet directory configured above. The trydir can be relative +to the user's home directory, but most of the time you will use an +explicit path like `~buildbot/project/trydir'. These arguments can be +provided in `.buildbot/options' as `try_host', `try_username', +`try_password', and `try_dir'. + + 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 +`--master' argument, or a `masterstatus' entry in `.buildbot/options', +in the form of a HOSTNAME:PORT string. + +choosing the Builders +===================== + +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"] + +specifying the VC system +======================== + +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=tla'. This can also be provided as `try_vc' in +`.buildbot/options'. + + The following names are recognized: `cvs' `svn' `baz' `tla' `hg' +`darcs' + +finding the top of the tree +=========================== + +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 +`--try-topfile=ChangeLog', or set it in the options file with +`try_topfile = 'ChangeLog''. + + You can also manually set the top of the tree with +`--try-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 (tla, baz, darcs, monotone, mercurial, git) do not require +`try' to know the top directory, so the `--try-topfile' and +`--try-topdir' arguments will be ignored. + + If the `try' command cannot find the top directory, it will abort +with an error message. + +determining the branch name +=========================== + +Some VC systems record the branch information in a way that "try" can +locate it, in particular Arch (both `tla' and `baz'). 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. + +determining the revision and patch +================================== + +Each VC system has a separate approach for determining the tree's base +revision and computing a patch. + +`CVS' + `try' pretends that the tree is up to date. It converts the + current time into a `-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. + +`SVN' + `try' does a `svn 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. + +`baz' + `try' does a `baz tree-id' to determine the fully-qualified + version and patch identifier for the tree + (ARCHIVE/VERSION-patch-NN), and uses the VERSION-patch-NN + component as the base revision. It then does a `baz diff' to + obtain the patch. + +`tla' + `try' does a `tla tree-version' to get the fully-qualified + version identifier (ARCHIVE/VERSION), then takes the first line + of `tla logs --reverse' to figure out the base revision. Then it + does `tla changes --diffs' to obtain the patch. + +`Darcs' + `darcs changes --context' emits a text file that contains a list + of all patches back to and including the last tag 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. + + So `try' does a `darcs changes --context' to determine what your + tree's base revision is, and then does a `darcs diff -u' to + compute the patch relative to that revision. + +`Mercurial' + `hg identify' emits a short revision ID (basically a truncated + SHA1 hash of the current revision's contents), which 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' + `step.Mercurial' will use. + +`Git' + `git 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. + + +waiting for results +=================== + +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. + +* Menu: + +* try --diff:: + + +File: buildbot.info, Node: try --diff, Prev: try, Up: try + +8.2.3.1 try -diff +................. + +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', +`--try-topfile', or `--try-topdir'. These options will be ignored. Of +course you must still specify how to get to the buildmaster (with +`--connect', `--tryhost', etc). + + +File: buildbot.info, Node: Other Tools, Next: .buildbot config directory, Prev: Developer Tools, Up: Command-line tool + +8.3 Other Tools +=============== + +These tools are generally used by buildmaster administrators. + +* Menu: + +* sendchange:: +* debugclient:: + + +File: buildbot.info, Node: sendchange, Next: debugclient, Prev: Other Tools, Up: Other Tools + +8.3.1 sendchange +---------------- + +This command is used to tell the buildmaster about source changes. It +is intended to be used from within a commit script, installed on the +VC server. It requires that you have a PBChangeSource (*note +PBChangeSource::) running in the buildmaster (by being set in +`c['change_source']'). + + buildbot sendchange --master MASTERHOST:PORT --username USER FILENAMES.. + + There are other (optional) arguments which can influence the +`Change' that gets submitted: + +`--branch' + This provides the (string) branch specifier. If omitted, it + defaults to None, indicating the "default branch". All files + included in this Change must be on the same branch. + +`--category' + This provides the (string) category specifier. If omitted, it + defaults to None, indicating "no category". The category + property is used by Schedulers to filter what changes they + listen to. + +`--revision_number' + This provides a (numeric) revision number for the change, used + for VC systems that use numeric transaction numbers (like + Subversion). + +`--revision' + This provides a (string) revision specifier, for VC systems that + use strings (Arch would use something like patch-42 etc). + +`--revision_file' + This provides a filename which will be opened and the contents + used as the revision specifier. This is specifically for Darcs, + which uses the output of `darcs changes --context' as a revision + specifier. This context file can be a couple of kilobytes long, + spanning a couple lines per patch, and would be a hassle to pass + as a command-line argument. + +`--comments' + This provides the change comments as a single argument. You may + want to use `--logfile' instead. + +`--logfile' + This instructs the tool to read the change comments from the + given file. If you use `-' as the filename, the tool will read + the change comments from stdin. + + +File: buildbot.info, Node: debugclient, Prev: sendchange, Up: Other Tools + +8.3.2 debugclient +----------------- + + buildbot debugclient --master MASTERHOST:PORT --passwd DEBUGPW + + This launches a small Gtk+/Glade-based debug tool, connecting to +the buildmaster's "debug port". This debug port shares the same port +number as the slaveport (*note Setting the slaveport::), but the +`debugPort' is only enabled if you set a debug password in the +buildmaster's config file (*note Debug options::). The `--passwd' +option must match the `c['debugPassword']' value. + + `--master' can also be provided in `.debug/options' by the +`master' key. `--passwd' can be provided by the `debugPassword' key. + + The `Connect' button must be pressed before any of the other +buttons will be active. This establishes the connection to the +buildmaster. The other sections of the tool are as follows: + +`Reload .cfg' + Forces the buildmaster to reload its `master.cfg' file. This is + equivalent to sending a SIGHUP to the buildmaster, but can be + done remotely through the debug port. Note that it is a good + idea to be watching the buildmaster's `twistd.log' as you reload + the config file, as any errors which are detected in the config + file will be announced there. + +`Rebuild .py' + (not yet implemented). The idea here is to use Twisted's + "rebuild" facilities to replace the buildmaster's running code + with a new version. Even if this worked, it would only be used + by buildbot developers. + +`poke IRC' + This locates a `words.IRC' status target and causes it to emit a + message on all the channels to which it is currently connected. + This was used to debug a problem in which the buildmaster lost + the connection to the IRC server and did not attempt to + reconnect. + +`Commit' + This allows you to inject a Change, just as if a real one had + been delivered by whatever VC hook you are using. You can set + the name of the committed file and the name of the user who is + doing the commit. Optionally, you can also set a revision for + the change. If the revision you provide looks like a number, it + will be sent as an integer, otherwise it will be sent as a + string. + +`Force Build' + This lets you force a Builder (selected by name) to start a + build of the current source tree. + +`Currently' + (obsolete). This was used to manually set the status of the given + Builder, but the status-assignment code was changed in an + incompatible way and these buttons are no longer meaningful. + + + +File: buildbot.info, Node: .buildbot config directory, Prev: Other Tools, Up: Command-line tool + +8.4 .buildbot config directory +============================== + +Many of the `buildbot' tools must be told how to contact the +buildmaster that they interact with. This specification can be +provided as a command-line argument, but most of the time it will be +easier to set them in an "options" file. The `buildbot' command will +look for a special directory named `.buildbot', starting from the +current directory (where the command was run) and crawling upwards, +eventually looking in the user's home directory. It will look for a +file named `options' in this directory, and will evaluate it as a +python script, looking for certain names to be set. You can just put +simple `name = 'value'' pairs in this file to set the options. + + For a description of the names used in this file, please see the +documentation for the individual `buildbot' sub-commands. The +following is a brief sample of what this file's contents could be. + + # for status-reading tools + masterstatus = 'buildbot.example.org:12345' + # for 'sendchange' or the debug port + master = 'buildbot.example.org:18990' + debugPassword = 'eiv7Po' + +`masterstatus' + Location of the `client.PBListener' status port, used by + `statuslog' and `statusgui'. + +`master' + Location of the `debugPort' (for `debugclient'). Also the + location of the `pb.PBChangeSource' (for `sendchange'). Usually + shares the slaveport, but a future version may make it possible + to have these listen on a separate port number. + +`debugPassword' + Must match the value of `c['debugPassword']', used to protect the + debug port, for the `debugclient' command. + +`username' + Provides a default username for the `sendchange' command. + + + The following options are used by the `buildbot try' command +(*note try::): + +`try_connect' + This specifies how the "try" command should deliver its request + to the buildmaster. The currently accepted values are "ssh" and + "pb". + +`try_builders' + Which builders should be used for the "try" build. + +`try_vc' + This specifies the version control system being used. + +`try_branch' + This indicates that the current tree is on a non-trunk branch. + +`try_topdir' + +`try_topfile' + Use `try_topdir' to explicitly indicate the top of your working + tree, or `try_topfile' to name a file that will only be found in + that top-most directory. + +`try_host' + +`try_username' + +`try_dir' + When try_connect is "ssh", the command will pay attention to + `try_host', `try_username', and `try_dir'. + +`try_username' + +`try_password' + +`try_master' + Instead, when `try_connect' is "pb", the command will pay + attention to `try_username', `try_password', and `try_master'. + +`try_wait' + +`masterstatus' + `try_wait' and `masterstatus' are used to ask the "try" command + to wait for the requested build to complete. + + + +File: buildbot.info, Node: Resources, Next: Developer's Appendix, Prev: Command-line tool, Up: Top + +9 Resources +*********** + +The Buildbot's home page is at `http://buildbot.sourceforge.net/' + + For configuration questions and general discussion, please use the +`buildbot-devel' mailing list. The subscription instructions and +archives are available at +`http://lists.sourceforge.net/lists/listinfo/buildbot-devel' + + +File: buildbot.info, Node: Developer's Appendix, Next: Index of Useful Classes, Prev: Resources, Up: Top + +Developer's Appendix +******************** + +This appendix contains random notes about the implementation of the +Buildbot, and is likely to only be of use to people intending to +extend the Buildbot's internals. + + The buildmaster consists of a tree of Service objects, which is +shaped as follows: + + BuildMaster + ChangeMaster (in .change_svc) + [IChangeSource instances] + [IScheduler instances] (in .schedulers) + BotMaster (in .botmaster) + [IBuildSlave instances] + [IStatusTarget instances] (in .statusTargets) + + The BotMaster has a collection of Builder objects as values of its +`.builders' dictionary. + + +File: buildbot.info, Node: Index of Useful Classes, Next: Index of master.cfg keys, Prev: Developer's Appendix, Up: Top + +Index of Useful Classes +*********************** + +This is a list of all user-visible classes. There are the ones that +are useful in `master.cfg', the buildmaster's configuration file. +Classes that are not listed here are generally internal things that +admins are unlikely to have much use for. + +Change Sources +============== + + +* Menu: + +* buildbot.changes.bonsaipoller.BonsaiPoller: BonsaiPoller. (line 6) +* buildbot.changes.freshcvs.FreshCVSSource: CVSToys - PBService. + (line 6) +* buildbot.changes.mail.BonsaiMaildirSource: BonsaiMaildirSource. + (line 6) +* buildbot.changes.mail.FCMaildirSource: FCMaildirSource. (line 6) +* buildbot.changes.mail.SVNCommitEmailMaildirSource: SVNCommitEmailMaildirSource. + (line 6) +* buildbot.changes.mail.SyncmailMaildirSource: SyncmailMaildirSource. + (line 6) +* buildbot.changes.p4poller.P4Source: P4Source. (line 6) +* buildbot.changes.pb.PBChangeSource: PBChangeSource. (line 6) +* buildbot.changes.svnpoller.SVNPoller: SVNPoller. (line 6) + +Schedulers and Locks +==================== + + +* Menu: + +* buildbot.locks.LockAccess: Interlocks. (line 6) +* buildbot.locks.MasterLock: Interlocks. (line 6) +* buildbot.locks.SlaveLock: Interlocks. (line 6) +* buildbot.scheduler.AnyBranchScheduler: AnyBranchScheduler. (line 6) +* buildbot.scheduler.Dependent: Dependent Scheduler. + (line 6) +* buildbot.scheduler.Nightly: Nightly Scheduler. (line 6) +* buildbot.scheduler.Periodic: Periodic Scheduler. (line 6) +* buildbot.scheduler.Scheduler: Scheduler Scheduler. + (line 6) +* buildbot.scheduler.Triggerable: Triggerable Scheduler. + (line 6) +* buildbot.scheduler.Try_Jobdir <1>: try. (line 32) +* buildbot.scheduler.Try_Jobdir: Try Schedulers. (line 6) +* buildbot.scheduler.Try_Userpass <1>: try. (line 32) +* buildbot.scheduler.Try_Userpass: Try Schedulers. (line 6) + +Build Factories +=============== + + +* Menu: + +* buildbot.process.factory.BasicBuildFactory: BuildFactory. (line 6) +* buildbot.process.factory.BasicSVN: BuildFactory. (line 6) +* buildbot.process.factory.BuildFactory: BuildFactory. (line 6) +* buildbot.process.factory.CPAN: CPAN. (line 6) +* buildbot.process.factory.Distutils: Python distutils. (line 6) +* buildbot.process.factory.GNUAutoconf: GNUAutoconf. (line 6) +* buildbot.process.factory.QuickBuildFactory: Quick builds. (line 6) +* buildbot.process.factory.Trial: Python/Twisted/trial projects. + (line 6) + +Build Steps +=========== + + +* Menu: + +* buildbot.steps.maxq.MaxQ: Index of Useful Classes. + (line 73) +* buildbot.steps.python.BuildEPYDoc: BuildEPYDoc. (line 6) +* buildbot.steps.python.PyFlakes: PyFlakes. (line 6) +* buildbot.steps.python.PyLint: PyLint. (line 6) +* buildbot.steps.python_twisted.BuildDebs: Python/Twisted/trial projects. + (line 6) +* buildbot.steps.python_twisted.HLint: Python/Twisted/trial projects. + (line 6) +* buildbot.steps.python_twisted.ProcessDocs: Python/Twisted/trial projects. + (line 6) +* buildbot.steps.python_twisted.RemovePYCs: Python/Twisted/trial projects. + (line 6) +* buildbot.steps.python_twisted.Trial: Python/Twisted/trial projects. + (line 6) +* buildbot.steps.shell.Compile: Compile. (line 6) +* buildbot.steps.shell.Configure: Configure. (line 6) +* buildbot.steps.shell.PerlModuleTest: PerlModuleTest. (line 6) +* buildbot.steps.shell.SetProperty: SetProperty. (line 6) +* buildbot.steps.shell.ShellCommand: ShellCommand. (line 6) +* buildbot.steps.shell.Test: Test. (line 6) +* buildbot.steps.shell.TreeSize: TreeSize. (line 6) +* buildbot.steps.source.Arch: Arch. (line 6) +* buildbot.steps.source.Bazaar: Bazaar. (line 6) +* buildbot.steps.source.Bzr: Bzr. (line 6) +* buildbot.steps.source.CVS: CVS. (line 6) +* buildbot.steps.source.Darcs: Darcs. (line 6) +* buildbot.steps.source.Git <1>: Index of Useful Classes. + (line 73) +* buildbot.steps.source.Git: Git. (line 6) +* buildbot.steps.source.Mercurial: Mercurial. (line 6) +* buildbot.steps.source.P4: P4. (line 6) +* buildbot.steps.source.SVN: SVN. (line 6) +* buildbot.steps.transfer.DirectoryUpload: Transferring Files. + (line 6) +* buildbot.steps.transfer.FileDownload: Transferring Files. (line 6) +* buildbot.steps.transfer.FileUpload: Transferring Files. (line 6) + +Status Targets +============== + + +* Menu: + +* buildbot.status.client.PBListener: PBListener. (line 6) +* buildbot.status.html.Waterfall: HTML Waterfall. (line 6) +* buildbot.status.mail.MailNotifier: MailNotifier. (line 6) +* buildbot.status.web.baseweb.WebStatus: WebStatus. (line 6) +* buildbot.status.words.IRC: IRC Bot. (line 6) + + +File: buildbot.info, Node: Index of master.cfg keys, Next: Index, Prev: Index of Useful Classes, Up: Top + +Index of master.cfg keys +************************ + +This is a list of all of the significant keys in master.cfg . Recall +that master.cfg is effectively a small python program with exactly one +responsibility: create a dictionary named `BuildmasterConfig'. The +keys of this dictionary are listed here. The beginning of the +master.cfg file typically starts with something like: + + BuildmasterConfig = c = {} + + Therefore a config key of `change_source' will usually appear in +master.cfg as `c['change_source']'. + + +* Menu: + +* c['buildbotURL']: Defining the Project. + (line 24) +* c['builders']: Defining Builders. (line 6) +* c['change_source']: Change Sources and Schedulers. + (line 6) +* c['debugPassword']: Debug options. (line 6) +* c['logCompressionLimit']: Defining the Project. + (line 36) +* c['manhole']: Debug options. (line 17) +* c['mergeRequests']: Merging BuildRequests. + (line 6) +* c['projectName']: Defining the Project. + (line 15) +* c['projectURL']: Defining the Project. + (line 19) +* c['properties']: Defining Global Properties. + (line 6) +* c['schedulers']: Change Sources and Schedulers. + (line 13) +* c['slavePortnum']: Setting the slaveport. + (line 6) +* c['slaves']: Buildslave Specifiers. + (line 6) +* c['sources']: Change Sources and Schedulers. + (line 6) +* c['status']: Defining Status Targets. + (line 11) + + +File: buildbot.info, Node: Index, Prev: Index of master.cfg keys, Up: Top + +Index +***** + + +* Menu: + +* addURL: BuildStep URLs. (line 6) +* Arch Checkout: Arch. (line 6) +* Bazaar Checkout: Bazaar. (line 6) +* Builder: Builder. (line 6) +* BuildRequest: BuildRequest. (line 6) +* BuildSet: BuildSet. (line 6) +* BuildStep URLs: BuildStep URLs. (line 6) +* Bzr Checkout: Bzr. (line 6) +* Configuration: Configuration. (line 6) +* CVS Checkout: CVS. (line 6) +* Darcs Checkout: Darcs. (line 6) +* Dependencies: Dependent Scheduler. + (line 6) +* Dependent: Dependent Scheduler. + (line 6) +* email: MailNotifier. (line 6) +* File Transfer: Transferring Files. (line 6) +* Git Checkout: Git. (line 6) +* installation: Installing the code. + (line 6) +* introduction: Introduction. (line 6) +* IRC: IRC Bot. (line 6) +* links: BuildStep URLs. (line 6) +* locks: Interlocks. (line 6) +* logfiles: Logfiles. (line 6) +* LogLineObserver: Adding LogObservers. + (line 6) +* LogObserver: Adding LogObservers. + (line 6) +* mail: MailNotifier. (line 6) +* Mercurial Checkout: Mercurial. (line 6) +* PBListener: PBListener. (line 6) +* Perforce Update: P4. (line 6) +* Philosophy of operation: History and Philosophy. + (line 6) +* Properties <1>: Using Build Properties. + (line 6) +* Properties <2>: Defining Global Properties. + (line 6) +* Properties <3>: Buildslave Specifiers. + (line 33) +* Properties <4>: Change Sources and Schedulers. + (line 41) +* Properties: Build Properties. (line 6) +* Scheduler: Schedulers. (line 6) +* statusgui: statusgui. (line 6) +* SVN Checkout: SVN. (line 6) +* treeStableTimer: BuildFactory Attributes. + (line 8) +* Triggers: Triggerable Scheduler. + (line 6) +* Users: Users. (line 6) +* Version Control: Version Control Systems. + (line 6) +* Waterfall: HTML Waterfall. (line 6) +* WebStatus: WebStatus. (line 6) +* WithProperties: Using Build Properties. + (line 34) + + |