[Buildbot-commits] buildbot/docs buildbot.texinfo,1.132,1.133
Brian Warner
warner at users.sourceforge.net
Thu Mar 20 17:43:11 UTC 2008
Update of /cvsroot/buildbot/buildbot/docs
In directory sc8-pr-cvs3.sourceforge.net:/tmp/cvs-serv30892/docs
Modified Files:
buildbot.texinfo
Log Message:
[project @ #56:trigger.patch]
Schedulers that can be triggered by buildsteps, allowing more
fine-grained control than Dependent schedulers.
Original author: dustin at v.igoro.us
Date: 2008-02-17 04:49:06+00:00
Index: buildbot.texinfo
===================================================================
RCS file: /cvsroot/buildbot/buildbot/docs/buildbot.texinfo,v
retrieving revision 1.132
retrieving revision 1.133
diff -u -d -r1.132 -r1.133
--- buildbot.texinfo 18 Mar 2008 20:36:14 -0000 1.132
+++ buildbot.texinfo 20 Mar 2008 17:43:09 -0000 1.133
@@ -2192,6 +2192,12 @@
scheduler is triggered. The next section (@pxref{Build Dependencies})
describes this scheduler in more detail.
+ at item Triggerable
+This scheduler does nothing until it is triggered by a Trigger
+step in another build. This facilitates a more general form of
+build dependencies, as described in the next section (@pxref{Build
+Dependencies}).
+
@item Periodic
This simple scheduler just triggers a build every N seconds.
@@ -2218,6 +2224,7 @@
@cindex Dependent
@cindex Dependencies
@slindex buildbot.scheduler.Dependent
+ at slindex buildbot.scheduler.Triggerable
It is common to wind up with one kind of build which should only be
performed if the same source code was successfully handled by some
@@ -2260,6 +2267,55 @@
@code{Scheduler} @emph{instance}, not a name. This makes it impossible
to create circular dependencies in the config file.
+A more general way to coordinate builds is by ``triggering'' schedulers
+from builds. The Triggerable waits to be triggered by a
+Trigger step in another build. That step can optionally
+wait for the scheduler's builds to complete. This provides two
+advantages over Dependent schedulers. First, the same scheduler
+can be triggered from multiple builds. Second, the ability to wait
+for a Triggerable's builds to complete provides a form of
+"subroutine call", where one or more builds can "call" a scheduler
+to perform some work for them, perhaps on other buildslaves.
+
+ at example
+from buildbot import scheduler
+from buildbot.steps import trigger
+checkin = scheduler.Scheduler("checkin", None, 5*60,
+ ["checkin"])
+nightly = scheduler.Scheduler("nightly", ...
+ ["nightly"])
+mktarball = scheduler.Triggerable("mktarball",
+ ["mktarball"])
+build = scheduler.Triggerable("build-all-platforms",
+ ["build-all-platforms"])
+test = scheduler.Triggerable("distributed-test",
+ ["distributed-test"])
+package = scheduler.Triggerable("package-all-platforms",
+ ["package-all-platforms"])
+c['schedulers'] = [checkin, nightly, build, test, package]
+
+checkin_factory = factory.BuildFactory()
+f.addStep(trigger.TriggerStep('mktarball',
+ schedulers=['mktarball'],
+ waitForFinish=1)
+f.addStep(trigger.TriggerStep('build',
+ schedulers=['build-all-platforms'],
+ waitForFinish=1)
+f.addStep(trigger.TriggerStep('test',
+ schedulers=['distributed-test'],
+ waitForFinish=1)
+
+nightly_factory = factory.BuildFactory()
+f.addStep(trigger.TriggerStep('mktarball',
+ schedulers=['mktarball'],
+ waitForFinish=1)
+f.addStep(trigger.TriggerStep('build',
+ schedulers=['build-all-platforms'],
+ waitForFinish=1)
+f.addStep(trigger.TriggerStep('package',
+ schedulers=['package-all-platforms'],
+ waitForFinish=1)
+ at end example
@node Setting the slaveport, Buildslave Specifiers, Listing Change Sources and Schedulers, Configuration
@section Setting the slaveport
@@ -3666,6 +3722,7 @@
* Simple ShellCommand Subclasses::
* Python BuildSteps::
* Transferring Files::
+* Triggering Schedulers::
* Writing New BuildSteps::
@end menu
@@ -4602,7 +4659,7 @@
@end table
- at node Python BuildSteps, Transferring Files, Simple ShellCommand Subclasses, Build Steps
+ at node Python BuildSteps, Triggering Schedulers, Simple ShellCommand Subclasses, Build Steps
@subsection Python BuildSteps
Here are some BuildSteps that are specifcally useful for projects
@@ -4678,7 +4735,7 @@
@end example
- at node Transferring Files, Writing New BuildSteps, Python BuildSteps, Build Steps
+ at node Transferring Files, Triggering Schedulers, Python BuildSteps, Build Steps
@subsection Transferring Files
@cindex File Transfer
@@ -4767,7 +4824,39 @@
creation time (@pxref{Buildslave Options}).
- at node Writing New BuildSteps, , Transferring Files, Build Steps
+ at node Triggering Schedulers, Writing New BuildSteps, Transferring Files, Build Steps
+ at subsection Triggering Schedulers
+
+The counterpart to the Triggerable described in section
+ at pxref{Build Dependencies} is the Trigger BuildStep.
+
+ at example
+from buildbot.steps.trigger import Trigger
+f.addStep(Trigger,
+ schedulers=['build-prep'],
+ waitForFinish=1,
+ updateSourceStamp=1)
+ at end example
+
+The @code{schedulers=} argument lists the Triggerables
+that should be triggered when this step is executed. Note that
+it is possible, but not advisable, to create a cycle where a build
+continually triggers itself, because the schedulers are specified
+by name.
+
+If @code{waitForFinish} is true, then the step will not finish until
+all of the builds from the triggered schedulers have finished. If this
+argument is not given, then the buildstep succeeds immediately after
+triggering the schedulers.
+
+If @code{updateSourceStamp} is true, then step updates the SourceStamp
+given to the Triggerables to include @code{got_revision}
+(the revision actually used in this build) as @code{revision} (the
+revision to use in the triggered builds). This is useful to ensure
+that all of the builds use exactly the same SourceStamp, even if
+other Changes have occurred while the build was running.
+
+ at node Writing New BuildSteps, , Triggering Schedulers, Build Steps
@subsection Writing New BuildSteps
While it is a good idea to keep your build process self-contained in
More information about the Commits
mailing list