zuul
/
zuul
Code Issues Proposed changes

Doc improvements on user guide 

This change:

  * fixes some spelling issues
  * externally links to a document describing what a 'git ref' is
  * links to executor document at the first reference to it
  * links to independent pipeline at the first reference to it

Change-Id: I3f2247deac15fd15c9dead6cba537d7b17e8491f
This commit is contained in:
David Shrewsbury 2017-08-03 15:53:59 -04:00
parent b8cb3da451
commit b040b0a7fb
4 changed files with 11 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
doc/source/admin/components.rst
View File

@ -229,6 +229,8 @@ Operation
To start the merger, run ``zuul-merger``. To stop it, kill the
PID which was saved in the pidfile specified in the configuration.
.. _executor:
Executor
--------

11
doc/source/user/concepts.rst
View File

@ -40,7 +40,8 @@ There are several reporting phases available; each of which may be
configured with any number of reporters. See :ref:`drivers` for a
full list of available reporters.
The items enqueued into a pipeline are each associated with a git ref.
The items enqueued into a pipeline are each associated with a
`git ref <https://git-scm.com/book/en/v2/Git-Internals-Git-References>`_.
That ref may point to a proposed change, or it may be the tip of a
branch or a tag. The triggering event determines the ref, and whether
it represents a proposed or merged commit. Zuul prepares the ref for
@ -67,7 +68,7 @@ after the change merges, depending on the type of project in which the
change appears.
Jobs specify the type and quantity of nodes which they require.
Before executing each job, Zuul will contact it's companion program,
Before executing each job, Zuul will contact its companion program,
Nodepool, to supply them. Nodepool may be configured to supply static
nodes or contact cloud providers to create or delete nodes as
necessary. The types of nodes available to Zuul are determined by the
@ -80,6 +81,6 @@ is also easy to use for simple tasks (such as executing a shell
script) or sophisticated deployment scenarios. When Zuul runs
Ansible, it attempts to do so in a manner most similar to the way that
Ansible might be used to orchestrate remote systems. Ansible itself
is run on the executor and acts remotely upon the test nodes supplied
to a job. This facilitates continuous delivery by making it possible
to use the same Ansible playbooks in testing and production.
is run on the :ref:`executor <executor>` and acts remotely upon the test
nodes supplied to a job. This facilitates continuous delivery by making it
possible to use the same Ansible playbooks in testing and production.

3
doc/source/user/gating.rst
View File

@ -227,7 +227,8 @@ behind them. See :ref:`project` for more details.
A given dependent pipeline may have as many shared change queues as
necessary, so groups of related projects may share a change queue
without interfering with unrelated projects. Independent pipelines do
without interfering with unrelated projects.
:value:`Independent pipelines <pipeline.manager.independent>` do
not use shared change queues, however, they may still be used to test
changes across projects using cross-project dependencies.

2
doc/source/user/index.rst
View File

@ -4,7 +4,7 @@ User's Guide
This guide is for all users of Zuul. If you work on a project where
Zuul is used to drive automation (whether that's testing proposed
changes, building artifacts, or deploying builds), this guide will
help you understand the concepts that underly Zuul, and how to
help you understand the concepts that underlie Zuul, and how to
configure it to meet your needs.