[Buildbot-commits] buildbot README,1.27,1.28 ChangeLog,1.535,1.536 NEWS,1.46,1.47
Brian Warner
warner at users.sourceforge.net
Tue Oct 25 02:49:56 UTC 2005
Update of /cvsroot/buildbot/buildbot
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv21959
Modified Files:
README ChangeLog NEWS
Log Message:
Revision: arch at buildbot.sf.net--2004/buildbot--dev--0--patch-390
Creator: Brian Warner <warner at lothar.com>
prepare for release
* README: update for 0.7.0
* NEWS: same
* docs/buildbot.texinfo: move the freshcvs stuff out of the README
Index: ChangeLog
===================================================================
RCS file: /cvsroot/buildbot/buildbot/ChangeLog,v
retrieving revision 1.535
retrieving revision 1.536
diff -u -d -r1.535 -r1.536
--- ChangeLog 25 Oct 2005 01:57:33 -0000 1.535
+++ ChangeLog 25 Oct 2005 02:49:53 -0000 1.536
@@ -1,5 +1,9 @@
2005-10-24 Brian Warner <warner at lothar.com>
+ * README: update for 0.7.0
+ * NEWS: same
+ * docs/buildbot.texinfo: move the freshcvs stuff out of the README
+
* buildbot/clients/debug.glade: add 'branch' box to fake-commit
* buildbot/clients/debug.py (DebugWidget.do_commit): same. Don't
send the branch= argument unless the user really provided one, to
Index: NEWS
===================================================================
RCS file: /cvsroot/buildbot/buildbot/NEWS,v
retrieving revision 1.46
retrieving revision 1.47
diff -u -d -r1.46 -r1.47
--- NEWS 24 Oct 2005 03:48:00 -0000 1.46
+++ NEWS 25 Oct 2005 02:49:53 -0000 1.47
@@ -1,19 +1,19 @@
User visible changes in Buildbot.
-* Release x.x.x (xx)
+* Release 0.7.0 (24 Oct 2005)
-* new features
+** new features
-** new c['schedulers'] config-file element (REQUIRED)
+*** new c['schedulers'] config-file element (REQUIRED)
The code which decides exactly *when* a build is performed has been massively
-refactored. YOU MUST UPDATE your master.cfg files to match: in general this
-will merely require you to add an appropriate c['schedulers'] entry. Any old
-".treeStableTime" settings on the BuildFactory instances will now be ignored.
-The user's manual has complete details with examples of how the new Scheduler
-classes work.
+refactored, enabling much more flexible build scheduling. YOU MUST UPDATE
+your master.cfg files to match: in general this will merely require you to
+add an appropriate c['schedulers'] entry. Any old ".treeStableTime" settings
+on the BuildFactory instances will now be ignored. The user's manual has
+complete details with examples of how the new Scheduler classes work.
-** c['interlocks'] removed, Locks and Dependencies now separate items
+*** c['interlocks'] removed, Locks and Dependencies now separate items
The c['interlocks'] config element has been removed, and its functionality
replaced with two separate objects. Locks are used to tell the buildmaster
@@ -23,7 +23,8 @@
otherwise your developers will be suffering from the same limitations). The
Lock object is created in the config file and then referenced by a Step
specification tuple or by the 'locks' key of the Builder specification
-dictionary.
+dictionary. Locks come in two flavors: MasterLocks are buildmaster-wide,
+while SlaveLocks are specific to a single buildslave.
When you want to have one Build run or not run depending upon whether some
other set of Builds have passed or failed, you use a special kind of
@@ -34,13 +35,13 @@
Both features are fully documented in the user's manual.
-** 'try'
+*** 'buildbot try'
-The 'buildbot try' feature has finally been added. There is some
-configuration involved, both in the buildmaster config and on the developer's
-side, but once in place this allows the developer to type 'buildbot try' in
-their locally-modified tree and to be given a report of what would happen if
-their changes were to be committed. This works by computing a (base revision,
+The 'try' feature has finally been added. There is some configuration
+involved, both in the buildmaster config and on the developer's side, but
+once in place this allows the developer to type 'buildbot try' in their
+locally-modified tree and to be given a report of what would happen if their
+changes were to be committed. This works by computing a (base revision,
patch) tuple that describes the developer's tree, sending that to the
buildmaster, then running a build with that source on a given set of
Builders. The 'buildbot try' tool then emits status messages until the builds
@@ -54,28 +55,32 @@
Instructions for developers who want to use 'try' (and the configuration
changes necessary to enable its use) are in the user's manual.
-** Build-On-Branch
+*** Build-On-Branch
When suitably configured, the buildbot can be used to build trees from a
variety of related branches. You can set up Schedulers to build a tree using
whichever branch was last changed, or users can request builds of specific
-branches through IRC, the web page, or the CLI 'buildbot force' subcommand.
+branches through IRC, the web page, or (eventually) the CLI 'buildbot force'
+subcommand.
The IRC 'force' command now takes --branch and --revision arguments (not that
they always make sense). Likewise the HTML 'force build' button now has an
input field for branch and revision. Your build's source-checkout step must
be suitably configured to support this: for SVN it involves giving both a
base URL and a default branch. Other VC systems are configured differently.
+The ChangeSource must also provide branch information: the 'buildbot
+sendchange' command now takes a --branch argument to help hook script writers
+accomplish this.
-** Multiple slaves per Builder
+*** Multiple slaves per Builder
You can now attach multiple buildslaves to each Builder. This can provide
-redundancy or load-balancing among many machines equally capable of running
-the build. To use this, define a key in the Builder specification dictionary
-named 'slavenames' with a list of buildslave names (instead of the usual
-'slavename' that contains just a single slavename).
+redundancy or primitive load-balancing among many machines equally capable of
+running the build. To use this, define a key in the Builder specification
+dictionary named 'slavenames' with a list of buildslave names (instead of the
+usual 'slavename' that contains just a single slavename).
-** minor new features
+*** minor new features
The IRC and email status-reporting facilities now provide more specific URLs
for particular builds, in addition to the generic buildmaster home page. The
@@ -99,7 +104,7 @@
** creeping version dependencies
-The IRC 'force build' command requires python2.3 (for the shlex.split
+The IRC 'force build' command now requires python2.3 (for the shlex.split
function).
Index: README
===================================================================
RCS file: /cvsroot/buildbot/buildbot/README,v
retrieving revision 1.27
retrieving revision 1.28
diff -u -d -r1.27 -r1.28
--- README 18 May 2005 08:01:36 -0000 1.27
+++ README 25 Oct 2005 02:49:53 -0000 1.28
@@ -56,19 +56,20 @@
available in python-2.1, and both master and slave require a version of
Twisted which only works with python-2.2 or later. Certain features (like
the inclusion of build logs in status emails) require python-2.2.2 or
- later.
+ later, while the IRC 'force' command requires python-2.3 .
Twisted: http://twistedmatrix.com
Both the buildmaster and the buildslaves require Twisted-1.3.0 or later.
- They have been briefly tested against Twisted-1.2.0, and might even work
- with Twisted-1.1.0, but 1.3.0 is the version that has received the most
- testing.
+ It has been mainly developed against Twisted-2.0.1, but has been tested
+ against Twisted-2.1.0 (the most recent as this time), and might even work
+ on versions as old as Twisted-1.1.0, but as always the most recent version
+ is recommended.
- Both work with Twisted-2.0.0 as well. You'll need at least "Twisted" (the
- core package), and you'll also want TwistedMail, TwistedWeb, and
- TwistedWords (for sending email, serving a web status page, and delivering
- build status via IRC, respectively).
+ When using the split subpackages of Twisted-2.x.x, you'll need at least
+ "Twisted" (the core package), and you'll also want TwistedMail,
+ TwistedWeb, and TwistedWords (for sending email, serving a web status
+ page, and delivering build status via IRC, respectively).
CVSToys: http://purl.net/net/CVSToys
@@ -80,8 +81,9 @@
INSTALLATION:
-Please read the User's Manual in docs/buildbot.info for complete
-instructions.
+Please read the User's Manual in docs/buildbot.info (or in HTML form on the
+buildbot web site) for complete instructions. This file only contains a brief
+summary.
RUNNING THE UNIT TESTS
@@ -89,20 +91,12 @@
PYTHONPATH=. trial -v buildbot.test
-This should run up to 124 tests, depending upon what VC tools you have
-installed. On my desktop machine it takes about two minutes to complete.
+This should run up to 175 tests, depending upon what VC tools you have
+installed. On my desktop machine it takes about four minutes to complete.
Nothing should fail, a few might be skipped. If any of the tests fail, you
should stop and investigate the cause before continuing the installation
process, as it will probably be easier to track down the bug early.
-If you want to test the VC checkout process, you'll need to install a
-tarball of repositories, available from http://buildbot.sf.net/ . Otherwise
-there are about 8 tests which will be skipped (all with names like testSVN
-and testArchHTTP). If you unpack this tarball in ~/tmp, it will create
-~/tmp/buildbot-test-vc-1, and you can enable the extra tests with:
-
- PYTHONPATH=. BUILDBOT_TEST_VC=~/tmp trial -v buildbot.test
-
INSTALLING THE LIBRARIES:
@@ -138,13 +132,14 @@
buildbot slave WORKDIR MASTERHOST:PORT SLAVENAME PASSWORD
-This will create a "TAP" file called "buildbot.tap", which bundles up all
-the state needed by the build slave application. Twisted has a tool called
-"twistd" which knows how to load these saved applications and start running
-them. twistd takes care of logging and daemonization (running the program in
-the background). /usr/bin/buildbot is a front end which runs twistd for you.
+This will create a file called "buildbot.tac", which bundles up all the state
+needed by the build slave application. Twisted has a tool called "twistd"
+which knows how to load these saved applications and start running them.
+twistd takes care of logging and daemonization (running the program in the
+background). /usr/bin/buildbot is a front end which runs twistd for you.
-Once you have the .tap file, you start it running like this:
+Once you've set up the directory with the .tac file, you start it running
+like this:
buildbot start WORKDIR
@@ -180,65 +175,14 @@
SETTING UP A BUILD MASTER:
-First, read through the rest of the documents to understand the definition
-of Builds and BuildFactories. Look at the docs in docs/*.xhtml.
-
-Second, know that this should get easier in the future, probably with a
-web-based interface to create new kinds of Builds and manipulate them.
-
-You start by picking a base directory where the buildmaster will store all
-its status and logfiles. Then you create the buildmaster's buildbot.tap file
-with the 'buildbot' tool:
-
- buildbot master WORKDIR
-
-This will also create a sample configuration file for you in
-WORKDIR/master.cfg . Edit this to describe how your buildmaster should
-operate: what port it should listen on for connections from the build slaves,
-which build slaves are allowed to connect, how to watch for changes to the
-source tree, how to run builds, and how to deliver status information.
-
-There are more examples in docs/examples/, and plenty of documentation on the
-various settings in docs/ . Everything is controlled by the config file. It
-must be readable from the master's basedir under the filename 'master.cfg'.
-
-Then you launch the buildmaster just as you would launch the buildslaves: the
-'buildbot' tool runs twistd, which automatically forks off the daemon into
-the background:
-
- buildbot start WORKDIR
-
-All buildmaster output is logged into 'twistd.log' in that same directory.
-
-The buildmaster will read master.cfg, set up the builders, start listening
-on the web server port and begin accepting connections from the buildslaves.
-
-
- CONNECTING TO A FRESHCVS DAEMON:
-
-Set up CVSToys-1.0.10, and add a statement like the following to your
-freshCfg file:
-
-pb = ConfigurationSet([
- (None, None, None, PBService(userpass=('foo', 'bar'), port=4519)),
- ])
-
-This will announce all changes to a client which connects to port 4519 using
-a username of 'foo' and a password of 'bar'.
-
-Then add a clause like this to your buildmaster's master.cfg:
-
-BuildmasterConfig['sources'] = [FreshCVSSource("cvs.example.com", 4519,
- "foo", "bar",
- prefix="glib/")]
+Please read the user's manual for instructions. The short form is that you
+use 'buildbot master MASTERDIR' to create the base directory, then you edit
+the 'master.cfg' file to configure the buildmaster. Once this is ready, you
+use 'buildbot START MASTERDIR' to launch it.
-where "cvs.example.com" is the host that is running the FreshCVS daemon, and
-"glib" is the top-level directory (relative to the repository's root) where
-all your source code lives. Most projects keep one or more projects in the
-same repository (along with CVSROOT/ to hold admin files like loginfo and
-freshCfg); the prefix= argument tells the buildmaster to ignore everything
-outside that directory, and to strip that common prefix from all pathnames
-it handles.
+A sample configuration file will be created for you in WORKDIR/master.cfg .
+There are more examples in docs/examples/, and plenty of documentation in the
+user's manual. Everything is controlled by the config file.
SUPPORT:
More information about the Commits
mailing list