The get_md5 parameter was removed with ansible 9.
https://docs.ansible.com/ansible/latest/porting_guides/porting_guide_9.html#id44
If it is being used the following error appears:
"Unsupported parameters for (stat) module: get_md5..."
Unrelated, but also blocking testing/merging of this change, the
Ansible version specs for older python versions is loosened
to allow installing older versions of Ansible on test nodes (like
focal) that have older pythons that are unsupported by newer Ansible.
Change-Id: I99dd4f16fde659d84eb3dfa191557b3d9508b0fb
This commit in Ansible:
9142be2f6c
now allows Python modules to specify their interpreter with the shebang.
We expect our roles to use the discovered python interpreter on remote
nodes, and on the executor, we need them to use the virtualenv. Removing
the specific shebang accomplishes this under Ansible 6, and has no effect
under older versions of Ansible.
Without this, for example, the log upload roles would not have access to
their cloud libraries.
Also update our ansible/cli check in our module files. Many of our modules
can be run from the command line for ease of testing, but the check that we
perform to determine if the module is being invoked from the command line
or Ansible fails on Ansible 5. Update it to a check that should work in
all 4 versions of Ansible that Zuul uses.
Change-Id: I4e6e85156459cca032e6c3e1d8a9284be919ccca
Add a testenv:py27 environment that overrides basepython to 2.7
Unfortunately implicit namespace packages are a Python3 thing [1] so
we have to scatter a few __init__.py's around for the test loader
under python2 to be able to find the unit test directories.
Update documenation to mention this
Needed-By: https://review.openstack.org/592768
[1] https://www.python.org/dev/peps/pep-0420/
Change-Id: I9a653666e8a083fb7f3fbb92589fe0467a41e6e6
Add a unit testing framework for python roles. Thanks to Matthew
Treinish for the suggestion of how to perform discovery (and much of the
code which is copied from Tempest).
Change-Id: Iec95dd1026a41614def57c65c3faa0516a682a5a
We're trying to move away from the legacy pbr 'build_sphinx' command.
However, without the relevant section in the 'setup.cfg' file, we have
no way to determine if the user wishes to use the '-W'
(warning-is-error) flag when building docs. The current behavior for
this is to default to False, meaning documentation for projects that
previously used the pbr functionality to enable warning-is-error is
liable to slowly break as time passes.
To resolve this, default to True for packages with no [build_sphinx]
section in setup.cfg. This ensures that projects migrating to the new
PTI (which, when fully implemented, involves removing the [build_sphinx]
section from setup.cfg) will be forced to fix any warnings prior to the
migration. However, packages that have not been converted will not be
broken. Only pacakges that have already fully switched over to the new
PTI but which did not have warning-is-error enabled are at risk of
unexpected breakage, but even for those the short-term pain should
ultimately be outweighed by the long-term gain.
Change-Id: I677afef96370ead5a45cba854ba483f18a8d1247
sphinx_warning_is_error and sphinx-pbr_autodoc are only useful for the
default documents living in doc/ - but not for api-ref, api-guide, etc.
Check for standard builds and do not run the "python setup.py
build_sphinx" or whereto for non-standard paths.
Change-Id: Ia8edd8a6ebc24f67a52d77c21b0cfa467e45a7ce
PBR supports two flags for autodoc in sphinx, autodoc_index_modules and
autodoc_tree_index_modules. We were only supporting
autodoc_index_modules but some projects like keystone use
autodoc_tree_index_modules. Address this by setting the autodoc flag to
true if either is set to true and defer to pbr to figure out what it
means.
Change-Id: If856e4b838d013781c0690b4ac1c2b37900d0fdd
There are a non-zero number of projects in OpenStack that are still
using pbr.autodoc_index_modules. Switching to the new sphinx build job
breaks them if they have warning-is-error turned on, as their docs are
expecting a reference to the autogenerated module doc indexes.
We should come up with a better solution for migrating them ... probably
a sphinx plugin that one can use with some options and whatnot. Or we
can commit a copy of the generated autoindex file and then treat it as
actual source code moving forward.
For now we need to run those projects with the pbr modified sphinx
builder. This adds support to the setup.cfg value lookup module
for looking up autodoc_index_modules and plumbs it in to the sphinx
invocation.
A note has also been left with an idea for how to simplify this and
remove the python module (we can ini lookup on the executor) but
implementing that is left as an exercise for later.
Change-Id: Ie0c9f24df09255e871f904e079b68809144b36b4
The first version of this change was broken, fix it with updating
roles/ensure-sphinx/tasks/main.yaml to run the test-requirements check
really on the remove node.
This reverts commit 68ded2251f34d2938eb7d91e846dd0e8ad6c892f.
Change-Id: I481e032834fdbf674157b2c9a8fa6f95fc570ddb
Some projects, such as Zuul itself, need to use python3 to build docs.
This adds a new parameter, sphinx_python, which defines the version
of python to build documentation with. The default is python2 and
projects can choose python3 on a need basis.
Remove the comment about the need for a leading comment, since there
is now a real need for the leading comment anyway.
Replace a few direct references to {{ ansible_user_dir }}/.venv that
should have been using zuul_work_virtualenv.
Update sphinx invocation to source the virtualenv activate first.
Some sphinx modules, such as sphinxcontrib.programoutput, attempt to
execute programs and only invoking sphinx-build with the relative
path causes the paths to not be set up properly.
Co-Authored-By: David Moreau Simard <dmsimard@redhat.com>
Change-Id: Ie5e2c93f88465f4aa746827ff88a585dbaa44fd5
Sphinx currently does not have a way to set warning-is-error in a config
file for builds that do not use python setup.py build_sphinx. It's
perfectly reasonable to use Sphinx for non-python languages, but putting
a setup.cfg into those projects is a bit weird. While we wait on getting
a config setting upstream, read the value out of setup.cfg ourselves if
it exists. This will let existing python projects with the setting work
as we expect, but will also let us just set a zuul variable for
non-python projects if we decide to not just put a setup.cfg in them.
Change-Id: Ie65dcb42c48e6a962f6715f7483ef3758caf2965
Sphinx jobs and reno jobs need basically the same thing for
dependencies. So make a new role, ensure-sphinx, which is
parameterizable enough that it can be used by both reno and sphinx jobs.
Make build jobs for both releasenotes and sphinx docs, as both of these
things are perfectly valid things to do in both OpenStack and
non-OpenStack contexts. We'll add an openstack specific job in
openstack-zuul-jobs that uses these as parents but adds the requirements
repo and constraints file settings.
Some of the pip commands here can be improved once
https://github.com/ansible/ansible/pull/33098 lands and is released,
which would allow specifying --user and -c as parameters to the pip
module.
Change-Id: Idd7caf7d88b56d61872906027b4ce7d743572ded
Needed-By: I57de14580f39b9e1c11a587b51b44b61b02c84da
