From 8721f23f8b155f0811ce9e5c1f7324023f38a65e Mon Sep 17 00:00:00 2001 From: Vitali Lovich Date: Sat, 16 May 2015 15:50:49 -0700 Subject: [PATCH] Update documentation --- master/docs/manual/cfg-buildsteps.rst | 2 ++ master/docs/manual/cfg-interlocks.rst | 2 ++ 2 files changed, 4 insertions(+) diff --git a/master/docs/manual/cfg-buildsteps.rst b/master/docs/manual/cfg-buildsteps.rst index dfb37f1cf59..2fb8f0c4526 100644 --- a/master/docs/manual/cfg-buildsteps.rst +++ b/master/docs/manual/cfg-buildsteps.rst @@ -144,6 +144,8 @@ Arguments common to all :class:`BuildStep` subclasses: ``locks`` a list of ``Locks`` (instances of :class:`buildbot.locks.SlaveLock` or :class:`buildbot.locks.MasterLock`) that should be acquired before starting this :class:`Step`. + Alternatively this could be a renderable that returns this list during build execution. + This lets you defer picking the locks to acquire until the build step is about to start running. The ``Locks`` will be released when the step is complete. Note that this is a list of actual :class:`Lock` instances, not names. Also note that all Locks must have unique names. diff --git a/master/docs/manual/cfg-interlocks.rst b/master/docs/manual/cfg-interlocks.rst index 7ef63e94e97..c112c1a0bfd 100644 --- a/master/docs/manual/cfg-interlocks.rst +++ b/master/docs/manual/cfg-interlocks.rst @@ -138,6 +138,8 @@ Each slave performs the same checkout, make, and test build step sequence. We want to enforce that at most one test step is executed between all slaves due to restrictions with the data base server. This is done by adding the ``locks=`` parameter with the third step. It takes a list of locks with their access mode. +Alternatively, this can take a renderable that returns an list of locks with their access mode. + In this case only the :data:`db_lock` is needed. The exclusive access mode is used to ensure there is at most one slave that executes the test step.