Switch to openstackdocstheme 2.2.1 version. Using
this version will allow especially:
* Linking from HTML to PDF document
* Allow parallel building of documents
* Fix some rendering problems
Update Sphinx version as well.
Disable openstackdocs_auto_name to use 'project' variable as name.
Change pygments_style to 'native' since old theme version always used
'native' and the theme now respects the setting and using 'sphinx' can
lead to some strange rendering.
openstackdocstheme renames some variables, so follow the renames
before the next release removes them. A couple of variables are also
not needed anymore, remove them.
See also
http://lists.openstack.org/pipermail/openstack-discuss/2020-May/014971.html
Change-Id: If046b8dded45c939bf596fdc8ae95f0d34602054
Make a few cleanups:
- Remove obsolete sections from setup.cfg
- Switch to using sphinx-build
- Cleanup doc/source/conf.py to remove now obsolete content.
- Switch to openstackdocstheme version
- Remove install_command from tox.ini, the default is fine
- Fix docs warnings
Change-Id: Icf6a2d4229392e9d38af67567167b60d02d68019
The commands used by constraints need at least tox 2.0. Update to
reflect reality, which should help with local running of constraints
targets.
Change-Id: I75379e7a51e8debea71c47b97a09d174dc8c150d
We want to default to running all tox environments under python 3, so
set the basepython value in each environment.
We do not want to specify a minor version number, because we do not
want to have to update the file every time we upgrade python.
We do not want to set the override once in testenv, because that
breaks the more specific versions used in default environments like
py35 and py36.
Change-Id: Ia958ac1f73122200715797bed836c568efb990f6
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
This is a mechanically generated patch to complete step 1 of moving
the zuul job settings out of project-config and into each project
repository.
Because there will be a separate patch on each branch, the branch
specifiers for branch-specific jobs have been removed.
Because this patch is generated by a script, there may be some
cosmetic changes to the layout of the YAML file(s) as the contents are
normalized.
See the python3-first goal document for details:
https://governance.openstack.org/tc/goals/stein/python3-first.html
Change-Id: I42f1d2f325a7ba9785ebf33bbe76497f031d6bb4
Story: #2002586
Task: #24311
Extend the context with custom parameters to make it
generally available for custom actions and support
the separation of OpenStack actions from the core.
Change-Id: If5ea987f3d9d70c288b12f549434f9e8d6853c66
According to Openstack summit session [1],
stestr is maintained project to which all Openstack projects should migrate.
So we should switch to stestr.
[1] https://etherpad.openstack.org/p/YVR-python-pti
Change-Id: I753abb6ceae046e388357450a6cdb84af6e5fe74
These jobs should all stay in project-config.
Read https://docs.openstack.org/infra/manual/zuulv3.html (with just updated instructions merging) on what to migrate - and what not.
This repo does not need a zuul.yaml file.
This reverts commit bb577d358e.
Change-Id: I84bd00d1335bef2356cb9eb2ec201bd107387a9e
Creating and running workflows within a namespace will allow users to create
many workflows with the same name. This is useful when a user already has many
workflows that are connected to each other implemented and one of the workflow
names is already in use and the user does not want to edit the that workflow
and all the ones referencing it or merge them to a workbook.
blueprint create-and-run-workflows-within-a-namespace
Change-Id: I5a8e6c8761bfe31bf04026083c4755468f580429
Fix the Sphinx html_last_updated_fmt for Python3. The
html_last_updated_fmt option is interpeted as a byte string in
python3, causing Sphinx build to break. This patch makes it
utf-8 string.
Change-Id: I399b769c3d636e40094837764da6a914132a779c
* While implementing the previous spec ('Workflow Global Context')
we realized that the proposed language syntax is not enough
flexible and concise. The proposed spec replaces the issues of
the previous spec.
Change-Id: I7bc926698b7be0301919718f6caa854387bab7f6
The idea of policies is to document something related to the project
that isn't tied to a specific release and often isn't related to code.
For example, a policy could be related to how we organise or how we
agree to do code reviews.
This process is inspired by the policies used in TripleO and the policy
template is a direct copy of the one used in TripleO.
Change-Id: I05f5076a1559790bf6d0f7b68d528748a2acd20b