This error occurs when variables are null and
DEFAULT_JINJA2_NATIVE is enabled:
object of type 'NoneType' has no len()
Change-Id: I7c69be60b846c03e30a0a6e8893bf2f3a3d5e5b8
These tasks should be used with become like Debian.yaml, otherwise
error will occurred like this:
[Errno 13] Permission denied: '/etc/yum.repos.d/test.repo'
Change-Id: I9c6f0132536500d36ba0098b635b1858e05d7ccf
We do this because it better approximates a production environment and
it seems that devstack is better tested when tls-proxy is enabled.
Change-Id: If607caf301211181b4f37a2c7012f875de3d285c
We subclass the GCS Credentials class. We can't completely test
it without either hitting the live Google cloud or substantial
mocking, but we should be able to exercise most of the functionality
we typically use. Do that by asking it to load a token from disk
and assert that it adds that token to a fake request headers
dictionary.
This also corrects a "problem" detected by the test. The current
super() call uses the python3 form, which is fine in that all current
uses of this code are using python3, but we still run python27 tests
on this repo, so we'll use the python2/python3 compat syntax.
Change-Id: Ifa4209617f4be52008b6294ebd10f0deb9bd6a51
Setting tox_envlist to venv by default is unintuitive for
many users. Remove this behaviour and let default tox
behaviour be the same as running tox on the commandline.
Change-Id: I1b6d59ee4ebb7f6b3adcf4bd35d7148e83389008
The google-auth Credential class added some new variables in the
constructor; make sure that we call it in order to avoid later
reference errors.
Change-Id: I338a3368b90a6612801ba587982d3053bbd3ba78
The upload-afs-synchronize role was added with
I493d8829e3fd98e84f1b8f0e776e7ba41abf16c2 and used as part of the
artifact promote process for tarballs and other uploads. However the
role is useful as a generic way to upload results to AFS and avoid
some commonly hit caveats such as getting permissions flags wrong.
Expand the README to explain things a little more.
Change-Id: Ia643b02b503560d1057697fc5a7d143fd728b177
The ensure-pip role has an option to provide multiple interpreters to
use. If not specified, we default to ansible_python.executable. This
default includes the full path to the executable. Those manually
providing which interpreters to use will not know what the full path is,
only the versions they would like to use. To make things consistent,
this strips off the path so we just have the version (python, python3,
python3.8, etc).
Change-Id: I339afc08393e9c6b1d26a05cf13b6fdc151f46d5
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
The ensure-pip tasks will install python3-venv, but multiple
interpreters may be specified. This adds handling to make sure the venv
package is installed for all requested interpreters.
Change-Id: I670d5815bfc902f9c50a98df715ef60b61bab594
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
We're seeing when the shell command fails (for whatever reason) and since
it's failed_when: false, the subsequent tasks actually fail. We can
check if stdout is not defined as a failure condition because that means
the module itself failed and we should not continue to process the
next tasks since they depend on stdout being defined.. Additionally we
can add some retries to try again if possible.
Change-Id: Iabc1619009220c6f1c91b84f81d5262c4d9d8430
Related-Bug: #1885697
When you're running a multi-node job, it would be nice to see the
inventory hostname in this list, so if you want to say, monitor one of
the nodes, you don't have to guess which is which.
Change-Id: Ibf822d51711c74d963a7287eaeaa9a40ff074e79
A multi-arch manifist is a manifest list which has a different content-type
than a regular manifest. In order to re-tag the image correctly, tell
docker hub that we can accept both kinds of manifests, and re-upload
the one that it gives us. This will be a manifest list if it exists, or
a regular manifest if it doesn't.
Change-Id: I7863b0c824c0b3cb20f94ba67399e823a216092b
When using docker buildx to build a container image, use a temporary
registry to receive the built image instead of requiring a buildset
registry.
A multi-arch test is also added with a publication registry
using the same task list to reduce duplication.
Change-Id: Ib20d1c97f6cb63e0ff9d8888ea792d1941cd8690
Co-Authored-By: James E. Blair <jeblair@redhat.com>
To avoid errors in case of mirror race conditions, we currently
(try to) ignore mirror errors, and check for presence of the
reference after the mirror try. This requires having to play
tricks to avoid errors when the job is run in the check pipeline,
due to missing zuul.newrev. And for some reason, it does not seem
to work[1].
Instead of ignoring errors and running an additional check, let's
just retry the mirror operation three times.
The race is rare-enough that it's very unlikely that we would
hit it three times in a row.
[1] https://zuul.openstack.org/build/4966cd5617624d348fa0048de14f1f96
Change-Id: Ifa4f25ad8c961a1b2dbd9f07a3a1e4652b790c9c
The upload-git-mirror job currently reports failure when multiple
jobs run concurrently for the same repository (one of them succeeds,
the other fails because the state of the mirror was changed by the
successful one).
However, since the job generally runs a few minutes after the commit
that triggered it merged, the successful job usually mirrored the two
needed commits, so the failed mirror operation does not mean the
mirror is out-of-sync. This results in false negatives.
If zuul.newrev is provided, rather than report failure if the mirror
operation fails, we should report failure if, after the mirror operation,
the commit that triggered the job is still not present on the mirror.
Change-Id: Iadae26473f4c937384c8cea74329e389c563aeed
The 'package' module doesn't update any package lists before installing
packages which can cause problems if the package lists haven't been
updated in a while. So run 'apt-get update' before
installing pip.
Change-Id: I836f7faa25dd8c06d0158828e21226fbe93fbb40
We are facing some issues where the log upload to swift fails, but the
role is always succeeding. To get some more information about the
upload failures, we let the upload() method return those to the Ansible
module and provide them in the module's JSON result.
The equivalent change in the test-upload-logs-swift [1] role is
validated in [2].
[1] https://review.opendev.org/#/c/735503/1
[2] https://review.opendev.org/#/c/737441/
Change-Id: Ie0d4ea2f3365600eae0e572e4c0790b131d3b13e
This corrects the following error when upload-docker-image is
used in a release pipeline:
The task includes an option with an undefined variable.
The error was: 'dict object' has no attribute 'change'
Change-Id: I70cd566ddd0b931d635b20107d652f3591a133b6
The job zuul-jobs-test-ensure-python-pyenv tests the ensure-python role
but - as shown in https://review.opendev.org/#/c/737060/ - changes to
that role do not run the testsuite. Update the files list.
Change-Id: I8c60f55aef8389ee893010f9cf92eb8cd109f74b
