From e7ba48cf8edc685be8f10c5ee9716001fd5a6f88 Mon Sep 17 00:00:00 2001 From: Harry Borkhuis Date: Mon, 21 May 2012 14:28:29 +0200 Subject: [PATCH] Codebases documented for Trigger and Triggerable --- master/docs/manual/cfg-buildsteps.rst | 30 ++++++++++++++------------- master/docs/manual/cfg-schedulers.rst | 4 ++++ 2 files changed, 20 insertions(+), 14 deletions(-) diff --git a/master/docs/manual/cfg-buildsteps.rst b/master/docs/manual/cfg-buildsteps.rst index d85cb21ea48..da4a0722615 100644 --- a/master/docs/manual/cfg-buildsteps.rst +++ b/master/docs/manual/cfg-buildsteps.rst @@ -2415,30 +2415,32 @@ are added to the waterfall and the build detail web pages for each triggered build. If this argument is ``False`` (the default) or not given, then the buildstep succeeds immediately after triggering the schedulers. -The SourceStamp to use for the triggered build is controlled by the arguments -``updateSourceStamp``, ``alwaysUseLatest``, and ``sourceStamp``. If +The SourceStamps to use for the triggered build are controlled by the arguments +``updateSourceStamp``, ``alwaysUseLatest``, and ``sourceStamps``. If ``updateSourceStamp`` is ``True`` (the default), then step updates the -:class:`SourceStamp` given to the :bb:sched:`Triggerable` schedulers to include +:class:`SourceStamp`s given to the :bb:sched:`Triggerable` schedulers to include ``got_revision`` (the revision actually used in this build) as ``revision`` (the revision to use in the triggered builds). This is useful to ensure that -all of the builds use exactly the same :class:`SourceStamp`, even if other +all of the builds use exactly the same :class:`SourceStamp`s, even if other :class:`Change`\s have occurred while the build was running. If ``updateSourceStamp`` is False (and neither of the other arguments are -specified), then the exact same SourceStamp is used. If ``alwaysUseLatest`` is -True, then no SourceStamp is given, corresponding to using the latest revision -of the repository specified in the Source step. This is useful if the triggered -builds use to a different source repository. :class:`SourceStamp` accepts a -dictionary containing the keys ``branch``, ``revision``, ``branch``, -``repository``, ``project``, and optionally ``patch_level``, ``patch_level`` -and ``patch_subdir`` and creates the corresponding SourceStamp. All of -``updateSourceStamp``, ``alwaysUseLatest``, and ``sourceStamp`` can be -specified using properties. +specified), then the exact same SourceStamps are used. If ``alwaysUseLatest`` is +True, then no SourceStamps are given, corresponding to using the latest revisions +of the repositories specified in the Source steps. This is useful if the triggered +builds use to a different source repository. The argument ``sourceStamps`` +accepts a list of dictionaries containing the keys ``branch``, ``revision``, +``branch``, ``repository``, ``project``, and optionally ``patch_level``, +``patch_level`` and ``patch_subdir`` and creates the corresponding SourceStamps. +If only one sourceStamp has to be specified then the argument ``sourceStamp`` +can be used for a dictionary containing the keys mentioned above. The arguments +``updateSourceStamp``, ``alwaysUseLatest``, and ``sourceStamp`` can be specified +using properties. Two parameters allow control of the properties that are passed to the triggered scheduler. To simply copy properties verbatim, list them in the ``copy_properties`` parameter. To set properties explicitly, use the more sophisticated ``set_properties``, which takes a dictionary mapping property -names to values. You may use :ref:`WithProperties` here to dynamically +names to values. You may use :ref:`WithProperties` here to dynamically construct new property values. RPM-Related Steps diff --git a/master/docs/manual/cfg-schedulers.rst b/master/docs/manual/cfg-schedulers.rst index 8dd6116c7ce..6ced9d45155 100644 --- a/master/docs/manual/cfg-schedulers.rst +++ b/master/docs/manual/cfg-schedulers.rst @@ -676,6 +676,8 @@ 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. +The Triggerable-Scheduler supports multiple codebases. The scheduler filters out +all codebases from Trigger steps that are not configured in the scheduler. The parameters are just the basics: @@ -686,6 +688,8 @@ The parameters are just the basics: ``properties`` See :ref:`Configuring-Schedulers`. +``codebases`` + This class is only useful in conjunction with the :class:`Trigger` step. Here is a fully-worked example::