GitLab

Change-Id: Ia365e46bf58ebd6d17ec064e3a0114dd64278c77

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>

Change-Id: I62742dc43df5276f51805e259229405ba9b19362

This allows us to write out host-specific variables into the inventory
from external jobs.

Change-Id: I0c3d08f6446174cb38d5eebaeae1db9dceb956b2

Make it easier to find them.

Change-Id: I0e8ee7e3c9f6e55461168b97525b26625eb018f0

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>

Also fixes a bug where the workspace was created from the wrong directory.

Change-Id: I28b54b9aa57a3f449254574956701ee663618e8b

E106 rejects roles with '-' in their names, which is important
for collections, but these aren't collections.

https://docs.ansible.com/ansible/devel/dev_guide/developing_collections.html#roles-directory

Change-Id: I48f837e8d5bd7d0d9d708d728d93627deb4093cc

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

Change-Id: I9bd85cbbf334a8d8c57b4adabf633e7046c273fd

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