From 526926a5ab40d6cce80801a867c39f0c0474e264 Mon Sep 17 00:00:00 2001 From: Michael Prokop Date: Thu, 24 Oct 2013 16:16:57 +0200 Subject: [PATCH] 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 --- doc/source/launchers.rst | 2 +- doc/source/reporters.rst | 10 +++++----- doc/source/statsd.rst | 6 +++--- doc/source/zuul.rst | 10 +++++----- 4 files changed, 14 insertions(+), 14 deletions(-) diff --git a/doc/source/launchers.rst b/doc/source/launchers.rst index d8145ab147..5e74bf660f 100644 --- a/doc/source/launchers.rst +++ b/doc/source/launchers.rst @@ -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 ---------------------- diff --git a/doc/source/reporters.rst b/doc/source/reporters.rst index 18d35a13a2..63a86c4c86 100644 --- a/doc/source/reporters.rst +++ b/doc/source/reporters.rst @@ -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 diff --git a/doc/source/statsd.rst b/doc/source/statsd.rst index 7c9dfe24d2..d657fb200f 100644 --- a/doc/source/statsd.rst +++ b/doc/source/statsd.rst @@ -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 diff --git a/doc/source/zuul.rst b/doc/source/zuul.rst index 6adfa30f88..6b5d7c9ff9 100644 --- a/doc/source/zuul.rst +++ b/doc/source/zuul.rst @@ -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