Merge "Fix some inconsistent indentation in docs" into feature/zuulv3
diff --git a/doc/source/admin/drivers/gerrit.rst b/doc/source/admin/drivers/gerrit.rst
index 0efb195..470b4e8 100644
--- a/doc/source/admin/drivers/gerrit.rst
+++ b/doc/source/admin/drivers/gerrit.rst
@@ -77,82 +77,82 @@
The supported pipeline trigger options are:
**event**
-The event name from gerrit. Examples: ``patchset-created``,
-``comment-added``, ``ref-updated``. This field is treated as a
-regular expression.
+ The event name from gerrit. Examples: ``patchset-created``,
+ ``comment-added``, ``ref-updated``. This field is treated as a
+ regular expression.
**branch**
-The branch associated with the event. Example: ``master``. This
-field is treated as a regular expression, and multiple branches may
-be listed.
+ The branch associated with the event. Example: ``master``. This
+ field is treated as a regular expression, and multiple branches may
+ be listed.
**ref**
-On ref-updated events, the branch parameter is not used, instead the
-ref is provided. Currently Gerrit has the somewhat idiosyncratic
-behavior of specifying bare refs for branch names (e.g., ``master``),
-but full ref names for other kinds of refs (e.g., ``refs/tags/foo``).
-Zuul matches what you put here exactly against what Gerrit
-provides. This field is treated as a regular expression, and
-multiple refs may be listed.
+ On ref-updated events, the branch parameter is not used, instead the
+ ref is provided. Currently Gerrit has the somewhat idiosyncratic
+ behavior of specifying bare refs for branch names (e.g.,
+ ``master``), but full ref names for other kinds of refs (e.g.,
+ ``refs/tags/foo``). Zuul matches what you put here exactly against
+ what Gerrit provides. This field is treated as a regular
+ expression, and multiple refs may be listed.
**ignore-deletes**
-When a branch is deleted, a ref-updated event is emitted with a newrev
-of all zeros specified. The ``ignore-deletes`` field is a boolean value
-that describes whether or not these newrevs trigger ref-updated events.
-The default is True, which will not trigger ref-updated events.
+ When a branch is deleted, a ref-updated event is emitted with a
+ newrev of all zeros specified. The ``ignore-deletes`` field is a
+ boolean value that describes whether or not these newrevs trigger
+ ref-updated events. The default is True, which will not trigger
+ ref-updated events.
**approval**
-This is only used for ``comment-added`` events. It only matches if
-the event has a matching approval associated with it. Example:
-``code-review: 2`` matches a ``+2`` vote on the code review category.
-Multiple approvals may be listed.
+ This is only used for ``comment-added`` events. It only matches if
+ the event has a matching approval associated with it. Example:
+ ``code-review: 2`` matches a ``+2`` vote on the code review
+ category. Multiple approvals may be listed.
**email**
-This is used for any event. It takes a regex applied on the performer
-email, i.e. Gerrit account email address. If you want to specify
-several email filters, you must use a YAML list. Make sure to use non
-greedy matchers and to escapes dots!
-Example: ``email: ^.*?@example\.org$``.
+ This is used for any event. It takes a regex applied on the
+ performer email, i.e. Gerrit account email address. If you want to
+ specify several email filters, you must use a YAML list. Make sure
+ to use non greedy matchers and to escapes dots! Example: ``email:
+ ^.*?@example\.org$``.
**email_filter** (deprecated)
-A deprecated alternate spelling of *email*. Only one of *email* or
-*email_filter* should be used.
+ A deprecated alternate spelling of *email*. Only one of *email* or
+ *email_filter* should be used.
**username**
-This is used for any event. It takes a regex applied on the performer
-username, i.e. Gerrit account name. If you want to specify several
-username filters, you must use a YAML list. Make sure to use non greedy
-matchers and to escapes dots!
-Example: ``username: ^jenkins$``.
+ This is used for any event. It takes a regex applied on the
+ performer username, i.e. Gerrit account name. If you want to
+ specify several username filters, you must use a YAML list. Make
+ sure to use non greedy matchers and to escapes dots! Example:
+ ``username: ^jenkins$``.
**username_filter** (deprecated)
-A deprecated alternate spelling of *username*. Only one of *username* or
-*username_filter* should be used.
+ A deprecated alternate spelling of *username*. Only one of
+ *username* or *username_filter* should be used.
**comment**
-This is only used for ``comment-added`` events. It accepts a list of
-regexes that are searched for in the comment string. If any of these
-regexes matches a portion of the comment string the trigger is
-matched. ``comment: retrigger`` will match when comments
-containing 'retrigger' somewhere in the comment text are added to a
-change.
+ This is only used for ``comment-added`` events. It accepts a list
+ of regexes that are searched for in the comment string. If any of
+ these regexes matches a portion of the comment string the trigger is
+ matched. ``comment: retrigger`` will match when comments containing
+ 'retrigger' somewhere in the comment text are added to a change.
**comment_filter** (deprecated)
-A deprecated alternate spelling of *comment*. Only one of *comment* or
-*comment_filter* should be used.
+ A deprecated alternate spelling of *comment*. Only one of *comment*
+ or *comment_filter* should be used.
-*require-approval*
-This may be used for any event. It requires that a certain kind
-of approval be present for the current patchset of the change (the
-approval could be added by the event in question). It follows the
-same syntax as the :ref:`"approval" pipeline requirement
-<pipeline-require-approval>`. For each specified criteria there must
-exist a matching approval.
+**require-approval**
+ This may be used for any event. It requires that a certain kind of
+ approval be present for the current patchset of the change (the
+ approval could be added by the event in question). It follows the
+ same syntax as the :ref:`"approval" pipeline requirement
+ <pipeline-require-approval>`. For each specified criteria there must
+ exist a matching approval.
-*reject-approval*
-This takes a list of approvals in the same format as
-*require-approval* but will fail to enter the pipeline if there is
-a matching approval.
+**reject-approval**
+ This takes a list of approvals in the same format as
+ *require-approval* but will fail to enter the pipeline if there is a
+ matching approval.
Reporter Configuration
----------------------
diff --git a/doc/source/admin/drivers/github.rst b/doc/source/admin/drivers/github.rst
index 9aadf7f..0cbf895 100644
--- a/doc/source/admin/drivers/github.rst
+++ b/doc/source/admin/drivers/github.rst
@@ -65,71 +65,75 @@
following options.
**event**
-The event from github. Supported events are ``pull_request``,
-``pull_request_review``, and ``push``.
+ The event from github. Supported events are ``pull_request``,
+ ``pull_request_review``, and ``push``.
-A ``pull_request`` event will
-have associated action(s) to trigger from. The supported actions are:
+ A ``pull_request`` event will have associated action(s) to trigger
+ from. The supported actions are:
- *opened* - pull request opened
+ *opened* - pull request opened
- *changed* - pull request synchronized
+ *changed* - pull request synchronized
- *closed* - pull request closed
+ *closed* - pull request closed
- *reopened* - pull request reopened
+ *reopened* - pull request reopened
- *comment* - comment added on pull request
+ *comment* - comment added on pull request
- *labeled* - label added on pull request
+ *labeled* - label added on pull request
- *unlabeled* - label removed from pull request
+ *unlabeled* - label removed from pull request
- *status* - status set on commit
+ *status* - status set on commit
-A ``pull_request_review`` event will
-have associated action(s) to trigger from. The supported actions are:
+ A ``pull_request_review`` event will
+ have associated action(s) to trigger from. The supported actions are:
- *submitted* - pull request review added
+ *submitted* - pull request review added
- *dismissed* - pull request review removed
+ *dismissed* - pull request review removed
**branch**
-The branch associated with the event. Example: ``master``. This
-field is treated as a regular expression, and multiple branches may
-be listed. Used for ``pull_request`` and ``pull_request_review`` events.
+ The branch associated with the event. Example: ``master``. This
+ field is treated as a regular expression, and multiple branches may
+ be listed. Used for ``pull_request`` and ``pull_request_review``
+ events.
**comment**
-This is only used for ``pull_request`` ``comment`` actions. It accepts a
-list of regexes that are searched for in the comment string. If any of these
-regexes matches a portion of the comment string the trigger is matched.
-``comment: retrigger`` will match when comments containing 'retrigger'
-somewhere in the comment text are added to a pull request.
+ This is only used for ``pull_request`` ``comment`` actions. It
+ accepts a list of regexes that are searched for in the comment
+ string. If any of these regexes matches a portion of the comment
+ string the trigger is matched. ``comment: retrigger`` will match
+ when comments containing 'retrigger' somewhere in the comment text
+ are added to a pull request.
**label**
-This is only used for ``labeled`` and ``unlabeled`` ``pull_request`` actions.
-It accepts a list of strings each of which matches the label name in the
-event literally. ``label: recheck`` will match a ``labeled`` action when
-pull request is labeled with a ``recheck`` label. ``label: 'do not test'``
-will match a ``unlabeled`` action when a label with name ``do not test`` is
-removed from the pull request.
+ This is only used for ``labeled`` and ``unlabeled`` ``pull_request``
+ actions. It accepts a list of strings each of which matches the
+ label name in the event literally. ``label: recheck`` will match a
+ ``labeled`` action when pull request is labeled with a ``recheck``
+ label. ``label: 'do not test'`` will match a ``unlabeled`` action
+ when a label with name ``do not test`` is removed from the pull
+ request.
**state**
-This is only used for ``pull_request_review`` events. It accepts a list of
-strings each of which is matched to the review state, which can be one of
-``approved``, ``comment``, or ``request_changes``.
+ This is only used for ``pull_request_review`` events. It accepts a
+ list of strings each of which is matched to the review state, which
+ can be one of ``approved``, ``comment``, or ``request_changes``.
**status**
-This is used for ``pull-request`` and ``status`` actions. It accepts a
-list of strings each of which matches the user setting the status, the
-status context, and the status itself in the format of
-``user:context:status``. For example,
-``zuul_github_ci_bot:check_pipeline:success``.
+ This is used for ``pull-request`` and ``status`` actions. It accepts
+ a list of strings each of which matches the user setting the status,
+ the status context, and the status itself in the format of
+ ``user:context:status``. For example,
+ ``zuul_github_ci_bot:check_pipeline:success``.
**ref**
-This is only used for ``push`` events. This field is treated as a regular
-expression and multiple refs may be listed. GitHub always sends full ref
-name, eg. ``refs/tags/bar`` and this string is matched against the regexp.
+ This is only used for ``push`` events. This field is treated as a
+ regular expression and multiple refs may be listed. GitHub always
+ sends full ref name, eg. ``refs/tags/bar`` and this string is
+ matched against the regexp.
Reporter Configuration
----------------------
@@ -142,32 +146,31 @@
supplied to the reporter. It has the following options:
**status**
-String value (``pending``, ``success``, ``failure``) that the reporter should
-set as the commit status on github.
-``status: 'success'``
+ String value (``pending``, ``success``, ``failure``) that the
+ reporter should set as the commit status on github. ``status:
+ 'success'``
**status-url**
-String value for a link url to set in the github status. Defaults to the zuul
-server status_url, or the empty string if that is unset.
+ String value for a link url to set in the github status. Defaults to
+ the zuul server status_url, or the empty string if that is unset.
**comment**
-Boolean value (``true`` or ``false``) that determines if the reporter should
-add a comment to the pipeline status to the github pull request. Defaults
-to ``true``. Only used for Pull Request based events.
-``comment: false``
+ Boolean value (``true`` or ``false``) that determines if the
+ reporter should add a comment to the pipeline status to the github
+ pull request. Defaults to ``true``. Only used for Pull Request based
+ events. ``comment: false``
**merge**
-Boolean value (``true`` or ``false``) that determines if the reporter should
-merge the pull reqeust. Defaults to ``false``. Only used for Pull Request based
-events.
-``merge=true``
+ Boolean value (``true`` or ``false``) that determines if the
+ reporter should merge the pull reqeust. Defaults to ``false``. Only
+ used for Pull Request based events. ``merge=true``
**label**
-List of strings each representing an exact label name which should be added
-to the pull request by reporter. Only used for Pull Request based events.
-``label: 'test successful'``
+ List of strings each representing an exact label name which should
+ be added to the pull request by reporter. Only used for Pull Request
+ based events. ``label: 'test successful'``
**unlabel**
-List of strings each representing an exact label name which should be removed
-from the pull request by reporter. Only used for Pull Request based events.
-``unlabel: 'test failed'``
+ List of strings each representing an exact label name which should
+ be removed from the pull request by reporter. Only used for Pull
+ Request based events. ``unlabel: 'test failed'``
diff --git a/doc/source/admin/drivers/timer.rst b/doc/source/admin/drivers/timer.rst
index 574ee1e..c70df5c 100644
--- a/doc/source/admin/drivers/timer.rst
+++ b/doc/source/admin/drivers/timer.rst
@@ -19,6 +19,6 @@
pipeline will run in response to that event.
**time**
-The time specification in cron syntax. Only the 5 part syntax is
-supported, not the symbolic names. Example: ``0 0 * * *`` runs
-at midnight.
+ The time specification in cron syntax. Only the 5 part syntax is
+ supported, not the symbolic names. Example: ``0 0 * * *`` runs at
+ midnight.
diff --git a/doc/source/admin/drivers/zuul.rst b/doc/source/admin/drivers/zuul.rst
index a875457..a23c875 100644
--- a/doc/source/admin/drivers/zuul.rst
+++ b/doc/source/admin/drivers/zuul.rst
@@ -13,28 +13,28 @@
can simply be used by listing **zuul** as the trigger.
**event**
-The event name. Currently supported:
+ The event name. Currently supported:
- *project-change-merged* when Zuul merges a change to a project,
- it generates this event for every open change in the project.
+ *project-change-merged* when Zuul merges a change to a project, it
+ generates this event for every open change in the project.
*parent-change-enqueued* when Zuul enqueues a change into any
pipeline, it generates this event for every child of that
change.
**pipeline**
-Only available for ``parent-change-enqueued`` events. This is the
-name of the pipeline in which the parent change was enqueued.
+ Only available for ``parent-change-enqueued`` events. This is the
+ name of the pipeline in which the parent change was enqueued.
-*require-approval*
-This may be used for any event. It requires that a certain kind
-of approval be present for the current patchset of the change (the
-approval could be added by the event in question). It follows the
-same syntax as the :ref:`"approval" pipeline requirement
-<pipeline-require-approval>`. For each specified criteria there must
-exist a matching approval.
+**require-approval**
+ This may be used for any event. It requires that a certain kind of
+ approval be present for the current patchset of the change (the
+ approval could be added by the event in question). It follows the
+ same syntax as the :ref:`"approval" pipeline requirement
+ <pipeline-require-approval>`. For each specified criteria there must
+ exist a matching approval.
-*reject-approval*
-This takes a list of approvals in the same format as
-*require-approval* but will fail to enter the pipeline if there is
-a matching approval.
+**reject-approval**
+ This takes a list of approvals in the same format as
+ *require-approval* but will fail to enter the pipeline if there is a
+ matching approval.