This role allows users to supply a common variable and it will
contain all the logic to configure the correct repository based
on their operating system.
Co-Authored-By: Andreas Jaeger <aj@suse.com>
Change-Id: I4a3ab5f099c2e4671b78c751d8f0e8ccf2304afa
* Build role requires build target to be specified via a variable
* Ensure role checks for a specific version of Bazel and downloads
and installs if missing; defaults to v3.1.0 and downloading from
bazelbuild Github, but these can be overrriden using variables
* Also installs dependencies for Bazel; only supports Ubuntu/Debian
at present, but includes scope to extend for other platforms
* Includes test playbook and job
Change-Id: I83f198aaf20c2b3664bea6fc05edd3b4fca13a4f
This is part of the efforts to remove pip-and-virtualenv from our base
images [1].
There are some users who specifically require the virtualenv command
(perhaps, like dib, they have some code that uses the activate_this.py
mechanisms it provides wich venv does not).
This installs the virtualenv package for the currently running
distribution.
One of the main maintenance issues of pip-and-virtualenv is that tried
to ensure that "virtualenv" created a Python 2 environment always by
default. Now that we have Python 3 only distributions like current
Fedora, this is not something we can continue to do (even if we wanted
to, which we don't).
What owns virtualenv and what it produces in our heterogeneous
environment is messy, and I think the best we can do is document it as
done here.
[1] https://docs.opendev.org/opendev/infra-specs/latest/specs/cleanup-test-node-python.html
Change-Id: I97d8bfb970ed2b5aaa02a0813899014c94994066
Several roles are setting facts that are expected to be consumed by
roles following them; generally things like the path to installed
tools, etc.
Add a section to policy about this behaviour in general, noting it
should use the cachable flags to persist the values.
Add specific documentation notes in an "Output Variable" section for
roles currently implementing this behaviour.
Change-Id: I05657fec198176c7d7345e84293f4902c81fa30c
This role is intended to ensure that the `pip:` module, and jobs that
may wish to use `pip` from the shell, have the necessary requirements.
It is intended as a partial replacement for the pip-and-virtualenv
element in diskimage-builder, which currently pre-installs pip on our
infra CI images during image build.
We wish to remain broady compatible with this element, but not
replicate some of the more problematic areas of its implementation.
By default, this installs the system packages for pip and setuptools
(the latter being a requirement of the Ansible pip module, which
imports it directly, despite pip itself not requiring it).
In this role, we ensure the libraries for the currently running
ansible_python_interpreter version are installed.
There is provision to provide a flag to install the packages directly
from upstream via get-pip.py, although this is not recommended.
Story: #2007386
Task: #39309
Change-Id: Iac2d518a66caf1b801273225f75a0a748412903c
This change adds new jobs to run and combine phoronix test suite results.
Co-Authored-By: Nicolas Hicher <nhicher@redhat.com>
Change-Id: If94cdbd91c8d80393a71cd5c36690563de9edcd6
This patch adds a roles and jobs to run golangci-lint against a
a Golang project. It's a very popular tool for linting go code.
It also adds a simple framework which allows us to create dynamic
tests for file comments by defining a simple YAML file.
Change-Id: Ic8358541adaf7c3279383f0279cd3da7b446a6e0
This is an alternative to I98c80f657f38c5e1ed5f28e5d36988a3429ad1f8
which does not modify the upload script, but rather queries the API
and manifest for what to download.
The script is a hybrid of python and bash to not implement json API
parsing badly in bash, but not replicate curl badly in python either.
The script sanity checks for dependencies, which are considered pretty
standard for any developer who would be interested in downloading logs
like this.
The role writes out the script with the correct build values coded
into it, so a potential user just has to run it without any arguments
or modification.
Change-Id: Ic33732adbfd3210191bf4976c3ee316cfc50568e
This refactors the code inside helm-template which waits for all
pods to become Ready to move inside it's own seperate role instead
which can be used for other tasks.
Change-Id: Ibb234c46c49fe656cf918a7a4af115e0d26f23f0
This is a simple utility that provides the zuul_return functionality
for repos that need it encapsulating the existence of zuul_return.
For instance, system-config wanted to start doing this in a playbook
but linting the playbooks became super hard because of the new need
to have zuul installed for the zuul_return library. Just keep it here
in the family.
Change-Id: I6035009455f6434c2d6cfd976c7c6f414bdc2ae7
This adds a role which installs bazelisk if it is not already
present. It also adds a test job which exercises the role; the
job will be run on any changes to the new role.
Change-Id: I69b28b58338b46ec3fea696f9d97be4271ed6ae4
We have to be careful about avoiding outer loop loop_var conflicts in
ansible. Because the zuul-jobs roles are meant to be reconsumed
elsewhere we should not use 'item' loopvars and instead set them to
something a bit more unique.
We use a zj_ prefix to try and be unique to this repo and document this
convention.
Change-Id: I20b9327a914890e9eafcb2b36dc8c23fb472bc8f
The upload-afs role is actually fairly specialised for uploading docs
with its root-marker scheme. As we're moving more parts of our
infrastructure to publish via AFS I think it's worth making this quite
explicit by renaming the upload-afs role to upload-afs-roots. This
should be transparent as we call the renamed role, and once callers
have been migrated we can use the usual deprecation process.
Add a partner role, upload-afs-synchronize, which is more of a
straight copy with options to synchronize. This will be suitable for
uploading tarball and release artifacts. This is similar in concept
to the promotion job used by zuul [1], but in this case will be
focused on the extant publishing jobs in project-config which don't
currently use the artifact-reporting/promote process.
[1] https://opendev.org/opendev/base-jobs/src/branch/master/playbooks/artifacts/promote.yaml#L39
Change-Id: I493d8829e3fd98e84f1b8f0e776e7ba41abf16c2
Story: #2006598
Task: #38600
This role runs Helm template of a specific chart and then makes
sure that all resources become ready afterwards.
Change-Id: I62e160eac673d13bd1018b58fd36cae54e1482b4
We use this in a few different places and it's really useful
to collect all the logs of all containers.
Change-Id: Idc46a47f444bf48cd040f4f9724f3a6ee8bc8f8e
