Use default sphinx theme and index attributes
We need to be able to link to configuration attributes, and they
should show up in the index. To that end, add some sphinx
directives to support config objects and attributes. These handle
nesting so that when we get deep into nested yaml (eg,
pipeline.trigger.gerrit.event) the full path will appear in the
header for the attribute. The ancestors will not be as prominent.
This ends up looking like the python class.FUNCTION() headers
in the stdlib docs.
The implementation is based on, and is compatible with, the nascent
zuul-sphinx module. Once that is published, we can either move
this code into that module, or depend on that module and add these
directives to the domain it creates.
The sphinx theme is changed to the current Sphinx default. That
is the theme "alabaster" (note, this is distinct from the theme
named "default", which is the old python2 style theme). Alabaster
has top-notch typography, and most importantly, it renders the
kinds of nested descriptors we're using very well.
Change-Id: I673b20849dd808e8fbff33fa1a7524227d1a6011
diff --git a/doc/source/conf.py b/doc/source/conf.py
index 71c7697..80cde65 100644
--- a/doc/source/conf.py
+++ b/doc/source/conf.py
@@ -29,7 +29,7 @@
'sphinx.ext.autodoc',
'sphinxcontrib.blockdiag',
'sphinxcontrib.programoutput',
- 'oslosphinx'
+ 'zuul.sphinx.zuul',
]
#extensions = ['sphinx.ext.intersphinx']
#intersphinx_mapping = {'python': ('http://docs.python.org/2.7', None)}
@@ -89,7 +89,7 @@
# The theme to use for HTML and HTML Help pages. See the documentation for
# a list of builtin themes.
-html_theme = 'default'
+#html_theme = 'alabaster'
# Theme options are theme-specific and customize the look and feel of a theme
# further. For a list of options available for each theme, see the
diff --git a/doc/source/user/config.rst b/doc/source/user/config.rst
index 6b63e49..0e9d6cf 100644
--- a/doc/source/user/config.rst
+++ b/doc/source/user/config.rst
@@ -75,6 +75,8 @@
.. _pipeline:
+.. zuul:configobject:: Pipeline
+
Pipeline
~~~~~~~~
@@ -125,53 +127,60 @@
The attributes available on a pipeline are as follows (all are
optional unless otherwise specified):
-**name** (required)
- This is used later in the project definition to indicate what jobs
- should be run for events in the pipeline.
+.. zuul:attr:: name
+ :required:
-**manager** (required)
- There are currently two schemes for managing pipelines:
+ This is used later in the project definition to indicate what jobs
+ should be run for events in the pipeline.
- .. _independent_pipeline_manager:
+.. zuul:attr:: manager
+ :required:
- *independent*
- Every event in this pipeline should be treated as independent of
- other events in the pipeline. This is appropriate when the order of
- events in the pipeline doesn't matter because the results of the
- actions this pipeline performs can not affect other events in the
- pipeline. For example, when a change is first uploaded for review,
- you may want to run tests on that change to provide early feedback
- to reviewers. At the end of the tests, the change is not going to
- be merged, so it is safe to run these tests in parallel without
- regard to any other changes in the pipeline. They are independent.
+ There are currently two schemes for managing pipelines:
- Another type of pipeline that is independent is a post-merge
- pipeline. In that case, the changes have already merged, so the
- results can not affect any other events in the pipeline.
+ .. _independent_pipeline_manager:
- .. _dependent_pipeline_manager:
+ .. zuul:attr:: independent
- *dependent*
- The dependent pipeline manager is designed for gating. It ensures
- that every change is tested exactly as it is going to be merged
- into the repository. An ideal gating system would test one change
- at a time, applied to the tip of the repository, and only if that
- change passed tests would it be merged. Then the next change in
- line would be tested the same way. In order to achieve parallel
- testing of changes, the dependent pipeline manager performs
- speculative execution on changes. It orders changes based on
- their entry into the pipeline. It begins testing all changes in
- parallel, assuming that each change ahead in the pipeline will pass
- its tests. If they all succeed, all the changes can be tested and
- merged in parallel. If a change near the front of the pipeline
- fails its tests, each change behind it ignores whatever tests have
- been completed and are tested again without the change in front.
- This way gate tests may run in parallel but still be tested
- correctly, exactly as they will appear in the repository when
- merged.
+ Every event in this pipeline should be treated as independent of
+ other events in the pipeline. This is appropriate when the order
+ of events in the pipeline doesn't matter because the results of
+ the actions this pipeline performs can not affect other events in
+ the pipeline. For example, when a change is first uploaded for
+ review, you may want to run tests on that change to provide early
+ feedback to reviewers. At the end of the tests, the change is
+ not going to be merged, so it is safe to run these tests in
+ parallel without regard to any other changes in the pipeline.
+ They are independent.
- For more detail on the theory and operation of Zuul's dependent
- pipeline manager, see: :doc:`gating`.
+ Another type of pipeline that is independent is a post-merge
+ pipeline. In that case, the changes have already merged, so the
+ results can not affect any other events in the pipeline.
+
+ .. _dependent_pipeline_manager:
+
+ .. zuul:attr:: dependent
+
+ The dependent pipeline manager is designed for gating. It
+ ensures that every change is tested exactly as it is going to be
+ merged into the repository. An ideal gating system would test
+ one change at a time, applied to the tip of the repository, and
+ only if that change passed tests would it be merged. Then the
+ next change in line would be tested the same way. In order to
+ achieve parallel testing of changes, the dependent pipeline
+ manager performs speculative execution on changes. It orders
+ changes based on their entry into the pipeline. It begins
+ testing all changes in parallel, assuming that each change ahead
+ in the pipeline will pass its tests. If they all succeed, all
+ the changes can be tested and merged in parallel. If a change
+ near the front of the pipeline fails its tests, each change
+ behind it ignores whatever tests have been completed and are
+ tested again without the change in front. This way gate tests
+ may run in parallel but still be tested correctly, exactly as
+ they will appear in the repository when merged.
+
+ For more detail on the theory and operation of Zuul's dependent
+ pipeline manager, see: :doc:`gating`.
**allow-secrets**
This is a boolean which can be used to prevent jobs which require