Fix some inconsistent indentation in docs
Change-Id: Ic9ffad8870955c000230ebb45b4e72e588144f70
This commit is contained in:
James E. Blair
@@ -77,82 +77,82 @@ be able to invoke the ``gerrit stream-events`` command over SSH.
|
||||
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
|
||||
----------------------
|
||||
|
||||
@@ -65,71 +65,75 @@ A connection name with the github driver can take multiple events with the
|
||||
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 @@ A :ref:`connection<connections>` that uses the github driver must be
|
||||
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'``
|
||||
|
||||
@@ -19,6 +19,6 @@ defined in the configuration. Any job associated with the
|
||||
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.
|
||||
|
||||
@@ -13,28 +13,28 @@ Zuul events don't require a special connection or driver. Instead they
|
||||
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.
|
||||
|
||||
Reference in New Issue
Block a user