zuul
/
zuul
Code Issues Proposed changes

doc: fix typos, missing parentheses, upper/lower case 

Fix some minor typos, add a missing parentheses and
unify some upper vs lower case words.

Change-Id: I2b6c394238de8d16f8eb4a752c2495762b01a2c3
changes/46/53646/2
Michael Prokop 2013-10-24 16:16:57 +02:00
parent ae028838e4
commit 526926a5ab
4 changed files with 14 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
doc/source/launchers.rst
View File

@ -49,7 +49,7 @@ To enable the built-in server, see the ``gearman_server`` section of
``zuul.conf``. Be sure that the host allows connections from Zuul and
any workers (e.g., Jenkins masters) on TCP port 4730, and nowhere else
(as the Gearman protocol does not include any provision for
authentication.
authentication).
Gearman Jenkins Plugin
----------------------

10
doc/source/reporters.rst
View File

@ -5,11 +5,11 @@ Reporters
Zuul can communicate results and progress back to configurable
protocols. For example, after succeeding in a build a pipeline can be
configured to post a positive review back to gerrit.
configured to post a positive review back to Gerrit.
There are three stages when a report can be handled. That is on:
Start, Success or Failure. Each stage can have multiple reports.
For example, you can set verified on gerrit and send an email.
For example, you can set verified on Gerrit and send an email.
Gerrit
------
@ -18,7 +18,7 @@ Zuul works with standard versions of Gerrit by invoking the
``gerrit`` command over an SSH connection. It reports back to
Gerrit using SSH.
The dictionary passed to the gerrit reporter is used for ``gerrit
The dictionary passed to the Gerrit reporter is used for ``gerrit
review`` arguments, with the boolean value of ``true`` simply
indicating that the argument should be present without following it
with a value. For example, ``verified: 1`` becomes ``gerrit review
@ -28,7 +28,7 @@ with a value. For example, ``verified: 1`` becomes ``gerrit review
Gerrit Configuration
~~~~~~~~~~~~~~~~~~~~
The configuration for posting back to gerrit is shared with the gerrit
The configuration for posting back to Gerrit is shared with the Gerrit
trigger in zuul.conf as described in :ref:`zuulconf`.
SMTP
@ -39,7 +39,7 @@ A simple email reporter is also available.
SMTP Configuration
~~~~~~~~~~~~~~~~~~
zuul.conf contains the smtp server and default to/from as describe
zuul.conf contains the SMTP server and default to/from as describe
in :ref:`zuulconf`.
Each pipeline can overwrite the to or from address by providing

6
doc/source/statsd.rst
View File

@ -4,7 +4,7 @@ Statsd reporting
================
Zuul comes with support for the statsd protocol, when enabled and configured
(see below), the Zuul scheduler will emit raw metrics to a Statsd receiver
(see below), the Zuul scheduler will emit raw metrics to a statsd receiver
which let you in turn generate nice graphics. An example is OpenStack Zuul
status page: http://status.openstack.org/zuul/
@ -14,9 +14,9 @@ Configuration
Statsd support uses the statsd python module. Note that Zuul will start without
the statsd python module, so an existing Zuul installation may be missing it.
The configuration is done via environnement variables STATSD_HOST and
The configuration is done via environment variables STATSD_HOST and
STATSD_PORT. They are interpreted by the statsd module directly and there is no
such paremeter in zuul.conf yet. Your init script will have to initialize both
such parameter in zuul.conf yet. Your init script will have to initialize both
of them before launching Zuul.
Your init script most probably loads a configuration file named

10
doc/source/zuul.rst
View File

@ -314,7 +314,7 @@ explanation of each of the parameters::
*email_filter*
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
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_filter: ^.*?@example\.org$``.
@ -453,7 +453,7 @@ That kind of pipeline is nice to run regression or performance tests.
.. note::
The ``change-merged`` event does not include the commit sha1 which can be
hazardous, it would let you report back to Gerrit though. If you were to
build a tarball for a specific commit, you should consider insteading using
build a tarball for a specific commit, you should consider instead using
the ``ref-updated`` event which does include the commit sha1 (but lack the
Gerrit change number).
@ -601,11 +601,11 @@ can help avoid running unnecessary jobs.
Project Templates
"""""""""""""""""
Whenever you have lot of similiar projects (such as plugins for a project) you
Whenever you have lot of similar projects (such as plugins for a project) you
will most probably want to use the same pipeline configurations. The
project templates let you define pipelines and job name templates to trigger.
One can then just apply the template on its project which make it easier to
update several similiar projects. As an example::
update several similar projects. As an example::
project-templates:
# Name of the template
@ -672,7 +672,7 @@ then exit. While waiting to exit Zuul will queue Gerrit events and
save these events prior to exiting. When Zuul starts again it will
read these saved events and act on them.
If you need to abort zuul and intend to manually requeue changes for
If you need to abort Zuul and intend to manually requeue changes for
jobs which were running in its pipelines, prior to terminating you can
use the zuul-changes.py tool script to simplify the process. For
example, this would give you a list of Gerrit commands to reverify or