The kubectl we use is actually OpenShift and the version we're
using does not include support for the `--address` option.

However, based on testing, by default, 127.0.0.1 is the address
it listens on so we can drop that parameter for now.

Change-Id: Ic0f056078ec40189d16350f7ea6529e8c5f9f685

bzip2 is universal across different distributions, it's also
needed by the 'unarchive' module when running inside the executor.

Change-Id: I24ddff86b8962c902c3e541a72e8810c163cb0c9

We need this role in order for the new log browsing features in
the web UI to work.

Also, update the text to account for multiple log storage systems
supported by zuul-jobs now.

Change-Id: Ieb542bb80d46f487b8f49b51fd0de8de2e4f2708

When a secret is missing from a job that passes it to parent, we
do not validate it and instead try to use the decrypt method on
a NoneType, resulting in a very user unfriendly error:

    Unable to freeze job graph: 'NoneType' object has no
    attribute 'decrypt'

This change includes a fix should make it a lot more user friendly
of an error message.

Change-Id: If7cb8fa6f206acc76a11f2a8edfac2b43f9fd367

At the moment, Zuul only shows an error for the first unknown
project that it encounters.  However, it's possible that it may
encounter more than one so we gather a list of them and warn the
user with the entire list instead.

Change-Id: I110f63179240178b80b27da53cab2319e36a5600

We had a point-in-time workaround for the importlib issue with
tox-py35 that is no longer needed.

Change-Id: I5df0dc4ad87e5381c6d15926a6aa6ac332eb4b35

python-base is buster now, so this is not necessary. We can
just install bubblewrap and socat from buster directly.

Change-Id: If65f3c2d6367a7c79cf9d6d8f788021ba72cccd4

podman build can't build this Dockerfile if we use unprefixed
images.

Change-Id: I6f3c21fe38bf446b22dbf09e6ceadb98d0f29212

Replace our tox-py37 job with tox-py38, extend the list of trove
classifiers for Python versions in package metadata, and replace the
"py35" in the tox.ini envlist with just "py3" so that folks running
`tox` unqualified on their systems will use whatever python3
interpreter they have on hand (odds are it's in our supported range
these days). Also uncap python-daemon so we use a version compatible
with Python >=3.8.

Change-Id: I4b382bb89847d3ae2b20292d923c3c2211dfb254

Change-Id: Iebedeba265780c211df618b2f30e96c79b893864

To try to approach a more intuitive behavior for jobs which apply
to tags but are defined in-repo (or even for centrally defined
jobs which should behave differently on tags from different branches),
look up which branches contain the commit referenced by a tag and
use that list in branch matchers.

If a tag item is enqueued, we look up the branches which contain
the commit referenced by the tag.  If any of those branches match a
branch matcher, the matcher is considered to have matched.

This means that if a release job is defined on multiple branches,
the branch variant from each branch the tagged commit is on will be
used.

A typical case is for a tagged commit to appear in exactly one branch.
In that case, the most intuitive behavior (the version of the job
defined on that branch) occurs.

A less typical but perfectly reasonable case is that there are two
identical branches (ie, stable has just branched from master but not
diverged).  In this case, if an identical commit is merged to both
branches, then both variants of a release job will run.  However, it's
likely that these variants are identical anyway, so the result is
apparently the same as the previous case.  However if the variants
are defined centrally, then they may differ while the branch contents
are the same, causing unexpected behavior when both variants are
applied.

If two branches have diverged, it will not be possible for the same
commit to be added to both branches, so in that case, only one of
the variants will apply.  However, tags can be created retroactively,
so that even if a branch has diverged, if a commit in the history of
both branches is tagged, then both variants will apply, possibly
producing unexpected behavior.

Considering that the current behavior is to apply all variants of
jobs on tags all the time, the partial reduction of scope in the most
typical circumstances is probably a useful change.

Change-Id: I5734ed8aeab90c1754e27dc792d39690f16ac70c
Co-Authored-By: Tobias Henkel <tobias.henkel@bmw.de>

The documentation states that this flag is used to report the builds
page instead of the log url on a per-job base. While this is totally
fine, I don't think we should rely on this flag when building the
status/result url for the whole buildset.

Change-Id: I029063aec591a14a5225b2c6c6a9123a4daa6ca7

We should tell folks to make sure that start-zuul-console is included
in their base jobs.

Change-Id: I29a0d902c2c7b7bce3fe9daf89ba8802ea819a63

Rather than rely on the implicit docker-image provides/requires
list explicit per-image requirements for related jobs to reduce,
unecessarily serialization in change queues.

Depends-On: https://review.opendev.org/711119
Change-Id: Ife5c40cf196c469c503009c5135c78be2957d651

We currently request the user of the sender login for each incoming
event. This only contains static information so this can be easily
cached to reduce the amount of api requests towards github.

Log analysis shows that in our deployment around 10% of the api
requests are done to request users where a big portion of that are
duplicated (e.g. zuul itself). So this should show a very high cache
hit rate.

Change-Id: Ia6ab97ecdfad78e76b31ede5e8080407df6bc84d

This change lifts the host-vars blacklist for trusted context.

Change-Id: I59c2829adf2a641dc6761aed930ab28471432a9a

The global tox installation on our test nodes is affected by an
upstream issue[1].  Additionally, the virtualenv created by tox
under those conditions is also affected.  To work around this,
pin the version of importlib-resources in the global tox install,
as well as in Zuul's own requirements.

[1] https://gitlab.com/python-devs/importlib_resources/issues/83

Change-Id: I31ed50185a71d867a2ad512ef9b526c5b607ed5c

This corrects a problem in the error handler when some request
variables are undefined.

This also handles the case of a buildset with no builds; currently
the REST API omits the builds value in that case, so this updates
usages to handle it.

Change-Id: Ifa09990d08257244f17e77e5c8141bfd8c1cc4d7

Setup config will not set the base test config object rather return a new one.
This allows to setup multiple config objects which is needed in order to
instantiate mutliple schedulers enabling them to have different configs, e.g.
command socket.

Change-Id: Icc7ccc82f7ca766b0b56c38e706e6e3215342efa
Story: 2007192