Use reno for release notes
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
This commit is contained in:
parent
1243cf75f4
commit
f0314feb8c
58
NEWS.rst
58
NEWS.rst
|
@ -1,58 +0,0 @@
|
|||
Since 2.0.0:
|
||||
|
||||
* The push_change_refs option which specified that Zuul refs should be
|
||||
pushed to Gerrit has been removed.
|
||||
|
||||
* Git merge operations are now performed in a separate process. Run
|
||||
at least one instance of the ``zuul-merger`` program which is now
|
||||
included. Any number of Zuul-Mergers may be run in order to
|
||||
distribute the work of speculatively merging changes into git and
|
||||
serving the results to test workers. This system is designed to
|
||||
scale out to many servers, but one instance may be co-located with
|
||||
the Zuul server in smaller deployments. Several configuration
|
||||
options have moved from the ``zuul`` section to ``merger``.
|
||||
|
||||
Since 1.3.0:
|
||||
|
||||
* The Jenkins launcher is replaced with Gearman launcher. An internal
|
||||
Gearman server is provided, and there is a Gearman plugin for
|
||||
Jenkins, so migration to the new system should be fairly
|
||||
straightforward. See the Launchers section of the documentation for
|
||||
details.
|
||||
|
||||
* The custom parameter function signature has changed. It now takes a
|
||||
QueueItem as the first argument, rather than the Change. The
|
||||
QueueItem has the full context for why the change is being run
|
||||
(including the pipeline, items ahead and behind, etc.). The Change
|
||||
is still available via the "change" attribute on the QueueItem. The
|
||||
second argument is now the Job that is about to be run, and the
|
||||
parameter dictionary is shifted to the third position.
|
||||
|
||||
* The ZUUL_SHORT_* parameters have been removed (the same
|
||||
functionality may be achieved with a custom parameter function that
|
||||
matches all jobs).
|
||||
|
||||
* Multiple triggers are now supported (currently Gerrit and a simple
|
||||
Timer trigger are supported). Your layout.yaml file will need to
|
||||
change to add the key "gerrit:" inside of the "triggers:" list to
|
||||
specify a Gerrit trigger (and facilitate adding other kinds of
|
||||
triggers later). See the sample layout.yaml and Zuul section of the
|
||||
documentation.
|
||||
|
||||
* Some statsd keys have changed in a backwards incompatible way:
|
||||
* The counters and timers of the form zuul.job.{name} is now split
|
||||
into several keys of the form:
|
||||
zuul.pipeline.{pipeline-name}.job.{job-name}.{result}
|
||||
* Job names in statsd keys now have the '_' character substituted
|
||||
for the '.' character.
|
||||
|
||||
* The layout.yaml structure has changed to introduce configurable
|
||||
reporters. This requires restructuring the start/success/failure
|
||||
actions to include a dictionary of reporters and their parameters.
|
||||
See reporters in the docs and layout.yaml-sample.
|
||||
|
||||
* The zuul_url configuration option is required in zuul.conf. It
|
||||
specifies the URL of the git repositories that should be used by
|
||||
workers when fetching Zuul refs and is passed to the workers as the
|
||||
ZUUL_URL parameter. It should probably be set to
|
||||
"http://zuul-host-name/p/".
|
|
@ -34,6 +34,7 @@ extensions = [
|
|||
'zuul_sphinx',
|
||||
'zuul.sphinx.ansible',
|
||||
'zuul.sphinx.zuul',
|
||||
'reno.sphinxext',
|
||||
]
|
||||
#extensions = ['sphinx.ext.intersphinx']
|
||||
#intersphinx_mapping = {'python': ('http://docs.python.org/2.7', None)}
|
||||
|
|
|
@ -17,3 +17,4 @@ Zuul, though advanced users may find it interesting.
|
|||
docs
|
||||
ansible
|
||||
javascript
|
||||
releasenotes
|
||||
|
|
|
@ -0,0 +1,41 @@
|
|||
Release Notes
|
||||
=============
|
||||
|
||||
Zuul uses `reno`_ for release note management. When adding a noteworthy
|
||||
feature, fixing a noteworthy bug or introducing a behavior change that a
|
||||
user or operator should know about, it is a good idea to add a release note
|
||||
to the same patch.
|
||||
|
||||
Installing reno
|
||||
---------------
|
||||
|
||||
reno has a command, ``reno``, that is expected to be run by developers
|
||||
to create a new release note. The simplest thing to do is to install it locally
|
||||
with pip:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
pip install --user reno
|
||||
|
||||
Adding a new release note
|
||||
-------------------------
|
||||
|
||||
Adding a new release note is easy:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
reno new releasenote-slug
|
||||
|
||||
Where ``releasenote-slug`` is a short identifier for the release note.
|
||||
reno will then create a file in ``releasenotes/notes`` that contains an
|
||||
initial template with the available sections.
|
||||
|
||||
The file it creates is a yaml file. All of the sections except for ``prelude``
|
||||
contain lists, which will be combined with the lists from similar sections in
|
||||
other note files to create a bulleted list that will then be processed by
|
||||
Sphinx.
|
||||
|
||||
The ``prelude`` section is a single block of text that will also be
|
||||
combined with any other prelude sections into a single chunk.
|
||||
|
||||
.. _reno: https://docs.openstack.org/reno/latest/
|
|
@ -28,6 +28,7 @@ Contents:
|
|||
user/index
|
||||
admin/index
|
||||
developer/index
|
||||
releasenotes
|
||||
|
||||
.. toctree::
|
||||
:hidden:
|
||||
|
|
|
@ -0,0 +1,5 @@
|
|||
=============
|
||||
Release Notes
|
||||
=============
|
||||
|
||||
.. release-notes::
|
|
@ -0,0 +1,4 @@
|
|||
---
|
||||
prelude: >
|
||||
This is a placeholder releasenote. It should be removed as soon as we have
|
||||
a real one.
|
|
@ -9,6 +9,7 @@ testrepository>=0.0.17
|
|||
testtools>=0.9.32
|
||||
sphinxcontrib-programoutput
|
||||
sphinx-autodoc-typehints
|
||||
reno>=2.5.0 # Apache-2.0
|
||||
mock
|
||||
PyMySQL
|
||||
mypy
|
||||
|
|
Loading…
Reference in New Issue