[Buildbot-commits] buildbot/docs buildbot.texinfo,1.22,1.23

[Brian Warner]

Update of /cvsroot/buildbot/buildbot/docs
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv32254/docs

Modified Files:
	buildbot.texinfo 
Log Message:
Revision: arch at buildbot.sf.net--2004/buildbot--dev--0--patch-326
Creator:  Brian Warner <warner at lothar.com>

implement multiple slaves per Builder, allowing concurrent Builds

	* lots: implement multiple slaves per Builder, which means multiple
	current builds per Builder. Some highlights:
	* buildbot/interfaces.py (IBuilderStatus.getState): return a tuple
	of (state,currentBuilds) instead of (state,currentBuild)
	(IBuilderStatus.getCurrentBuilds): replace getCurrentBuild()
	(IBuildStatus.getSlavename): new method, so you can tell which
	slave got used. This only gets set when the build completes.
	(IBuildRequestStatus.getBuilds): new method

	* buildbot/process/builder.py (SlaveBuilder): add a .state
	attribute to track things like ATTACHING and IDLE and BUILDING,
	instead of..
	(Builder): .. the .slaves attribute here, which has been turned
	into a simple list of available slaves. Added a separate
	attaching_slaves list to track ones that are not yet ready for
	builds.
	(Builder.fireTestEvent): put off the test-event callback for a
	reactor turn, to make tests a bit more consistent.
	(Ping): cleaned up the slaveping a bit, now it disconnects if the
	ping fails due to an exception. This needs work, I'm worried that
	a code error could lead to a constantly re-connecting slave.
	Especially since I'm trying to move to a distinct remote_ping
	method, separate from the remote_print that we currently use.
	(BuilderControl.requestBuild): return a convenience Deferred that
	provides an IBuildStatus when the build finishes.
	(BuilderControl.ping): ping all connected slaves, only return True
	if they all respond.

	* buildbot/slave/bot.py (BuildSlave.stopService): stop trying to
	reconnect when we shut down.

	* buildbot/status/builder.py: implement new methods, convert
	one-build-at-a-time methods to handle multiple builds
	* buildbot/status/*.py: do the same in all default status targets
	* buildbot/status/html.py: report the build's slavename in the
	per-Build page, report all buildslaves on the per-Builder page

	* buildbot/test/test_run.py: update/create tests
	* buildbot/test/test_slaves.py: same
	* buildbot/test/test_scheduler.py: remove stale test

	* docs/buildbot.texinfo: document the new builder-specification
	'slavenames' parameter


Index: buildbot.texinfo
===================================================================
RCS file: /cvsroot/buildbot/buildbot/docs/buildbot.texinfo,v
retrieving revision 1.22
retrieving revision 1.23
diff -u -d -r1.22 -r1.23
--- buildbot.texinfo	2 Sep 2005 15:31:28 -0000	1.22
+++ buildbot.texinfo	14 Oct 2005 19:42:40 -0000	1.23
@@ -1839,6 +1839,22 @@
 @code{slavename} must appear in the @code{c['bots']} list. Each
 buildslave can accomodate multiple Builders.
 
+ at item slavenames
+If you provide @code{slavenames} instead of @code{slavename}, you can
+give a list of buildslaves which are capable of running this Builder.
+If multiple buildslaves are connected for any given Builder, it will
+be able to run multiple builds at the same time (one per slave). This
+can also provide a level of redundancy: in case one slave goes
+offline, the others can still keep the Builder working.
+
+If you use this feature, it is important to make sure that the
+buildslaves are all, in fact, capable of running the given build. The
+slave hosts should be configured similarly, otherwise you will spend a
+lot of time trying (unsuccessfully) to reproduce a failure that only
+occurs on some of the buildslaves and not the others. Different
+platforms, operating systems, versions of major programs or libraries,
+all these things mean you should use separate Builders.
+
 @item builddir
 This specifies the name of a subdirectory (under the base directory)
 in which everything related to this builder will be placed. On the