This is an attempt to formalize our governance structure, but it's
not really an attempt to change it. The goal has been to create
a governance structure which most closely resembles how we have
been operating for the past several years.
Change-Id: Ia692631353b5d2ac90ee4f9b9c615e4f7244a24d
The OpenStack Release team has created a great release notes management
tool that integrates with Sphinx. Start using it. For reference on how
to use it, see http://docs.openstack.org/developer/reno/
Add an initial release note with no contents so that the build flow and
docs integration can be verified. The note file can be removed later.
Change-Id: I254cd220fc8c0c06ee87f84f1fb5cbe3244f0fed
There are two other projects named zuul. Let's make sure we disambiguate
so users aren't confused.
Change-Id: I6c459d062970e2abcbb890d626297595d979d324
And start using it. Added some common terms to glossary.
I have not found a lot of source material yet to suggest the best
way to incorporate use of a glossary into the text, especially with
very frequently used technical terms like we have in some parts of
this documentation. So here are the guidelines I'm trying out:
* If the term is being defined in the text, don't like to the glossary
(that would be redundant), but do emphasize it with *italics* the
first time it appears in that definition. Subsequent uses within
the same subsection should be in regular type.
* If it's being used (but not defined) in the text, link the first usage
within a subsection to the glossary, but subsequent uses should be
in regular type.
* Be cognizant of how readers may jump to link targets within the text,
so be liberal in considering that once you cross a link target,
you may be in a new "subsection" for the above guideline.
This change also alters some use of literals to make them more consistent:
* Filenames and scalar values of attributes (not special keyword values
like 'independent') should be ``literal``.
* Most references to attribute names should be via the :attr: role, however,
for abbreviated local references (ie, to the current or previous attribute)
use **bold** to maintain the same style but without the long name and link.
Also, correct some spelling.
Change-Id: I7debd962c0300f1a7c357d825fc2642ada89df58
And make the zuul:configobject directive produce an actual node
so that links to it work as expected.
Change-Id: I8c4222b23a2d1f67eee23a6b70f4669277ca4dcd
Refresh the user and admin guide for v3 changes, and reorganize into
a narrative structure which makes more sense for v3.
Change-Id: I4ac3b18d5ed33b0fea4e2ef0318b19bfc3447ccc
Move developer docs to their own subdir (to avoid filename conflicts
with current doc set), and add a (very basic) new dev doc for triggers.
Change-Id: I0dce63ab9fa470247c4bbd4aae58dc97cdf8a517
To avoid confusion with nodepool-launcher, we've decided to rename
zuul-launcher to zuul-executor.
Change-Id: I7d03cf0f0093400f4ba2e4beb1c92694224a3e8c
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Re-organize the "internals" section into a "Developer's Guide" with
sub-pages and add the drivers documentation as one of them.
Change-Id: Ibdf0287a7a077dfeaac6c63d1c8beca8d5f3f4be
Sometimes having narrative text describing how objects hang together it
handy for knowing what to do.
Change-Id: Ib12af2d993740d82b4f43de74b11ecefd1cd363a
The intent is to replace the devstack shell script with a python utility
which would be easy to reuse.
Change-Id: I3c8748e2544af80e72fdd0b2e3627b4fc2212c01
Connect it to Zuul via Gearman. Any number of mergers may be
deployed.
Directly find the pipeline for a build when processing a result,
so that the procedure is roughly the same for build and merge
results.
The timer trigger currently requires the gerrit trigger also be
configured. Make that explicit inside of the timer trigger so
that the scheduler API interaction with triggers is cleaner.
Change-Id: I69498813764753c97c426e42d17596c2ef1d87cf
Adds programoutput sphinx extension as a test dependency so doc
builds can include the program help text.
Change-Id: Iec2f09f710162614cbb393a5628204ddebe2e29f
Allows multiple reports per a patchset to be sent to pluggable
destinations. These are configurable per pipeline and, if not
specified, defaults to the legacy behaviour of reporting back only
to gerrit.
Having multiple reporting methods means only certain success/failure
/start parameters will apply to certain reporters. Reporters are
listed as keys under each of those actions.
This means that each key under success/failure/start is a reporter and the
dictionaries under those are sent to the reporter to deal with.
Change-Id: I80d7539772e1485d5880132f22e55751b25ec198
Remove the Jenkins launcher and add a new Gearman launcher (designed
to be compatible with Jenkins) in its place.
See the documentation for how to set up the Gearman Plugin for
Jenkins.
Change-Id: Ie7224396271d7375f4ea42eebb57f883bc291738
James E. Blair