There was a bug in opendevorg/python-builder that prevented extras from
being installed properly. Zuul worked around this with an explicit step
to install those extras. The depends on of this change fixes the
python-builder bug so we can remove the workaround from Zuul's
dockerfile.

Depends-On: https://review.opendev.org/744531
Change-Id: I28a783ca0582669c7fe9045aa912908f4229fd29

I think that ConfigItemUnknownErorr is the wrong exception to raise
here.  It is being raised in response to a class mismatch which seems
like it should be a TypeError.

In the follow-on I4851a5a796fa452a023e0e6193fc724ae0967a44 I am
proposing that ConfigItemUnknownError and related exceptions provide
some context on config snippet that has caused the error, and there
isn't a value that makes sense here.

Change-Id: I824600783e4724684d76d4c4dbaa9e0b4e92c7e5

A ConfigurationError object makes a ConfigurationErrorKey from
<context, mark, error-string>.  The ConfigurationErrorKey assumes the
"mark" argument is a ZuulMark object that has fields such as "line"
and "snippet".

However there is a path to set config errors via
QueueItem.setConfigError(string) which makes a ConfigurationError with
<None, None, error-string>.  Consequently the "mark" object in the
ConfigurationErrorKey isn't actually a ZuulMark and the __eq__
comparision for ConfigurationErrorKey objects can fail.

This can hit in PipelineManager._findRelevantErrors() which walks the
error list and ends up doing a comparision with

  if ((err.key not in
       parent_layout.loading_errors.error_keys)

I think the result in production is that you can get a range of errors
that do not get reported.  I came to looking at this because I
accidentally added Ansible playbooks under .zuul.d and something was
clearly wrong, but I was not getting any error messages.

The solution here is to move the field matching for the ZuulMark into
an __eq__ method in the ZuulMark object itself, allowing None to be a
valid value.

Adding a file that looks like a playbook triggers this path for the
test_dynamic_split_config test, which passes with this fix.

Change-Id: If59f5556141db4bda54a61b459ffbffb935094ae

The canMerge method is called without the event id from a few places.

Change-Id: I3233bd840dd0cc10817077c081c52852352df2ff

This causes e.g. web requests that should be trackable via the event
id in the logs.

Change-Id: Iade2558f2312aedca7480b4ea1d3df60735cfc90

It was causing the branch to be protected, tests were failing

Change-Id: Idb7b3957159684787fe272181eee92af1abe0da1

hasUnparsedBranchCache 1st argument is expecting the project's canonical name.
This could lead to cache not being properly cleaned

As a result 2 tests needed a fix

1. a github test was no longer working. In the current test class, the tenant
is not configured to globaly or per project exclude unprotected branches, so a
reconfigure is to expect.

A copy of this test is added in TestGithubUnprotectedBranches to use a project
which has exclude-unprotected-branches enabled.

Various fixes are also included:
- getPushEvent: no mutable default argument [1]
- branch_updated only when required
- change test structure of similar tests to send the proper sha1 when deleting
  the branch

2. an exception appeared in test_pending_merge_in_reconfig:

Traceback (most recent call last):
  File "/home/safranaerosystemsfcs/zuul/zuul/zuul/scheduler.py", line 1347, in process_management_queue
    self._doTenantReconfigureEvent(event)
  File "/home/safranaerosystemsfcs/zuul/zuul/zuul/scheduler.py", line 911, in _doTenantReconfigureEvent
    project.canonical_name, branch)
AttributeError: 'NoneType' object has no attribute 'canonical_name'

after setting the project, the test was blocked during tenant reconfiguration.
It needs a merger to be completed.
This change reactivates the merger before starting a reconfigure.
Some additional checks are making sure the initial merge job did not complete

[1] https://docs.python-guide.org/writing/gotchas/#mutable-default-arguments

Change-Id: I1e0948944f71a74411e78e3b3e6b7eaf2ed36b63

Change-Id: I37ffd7829c77c9b0c196ae083cd7d9bce32512be

Change-Id: I2a35b45dfce7b439fe4dbbe68f2c461f3d01212e

Change-Id: Iac34f7883d1eda5179b707b3620d17b085bf135c

Change-Id: Icdaee4e9f60bd9ec9c38cec0456dcb0ed1851560

Change-Id: I26a70fa81ed0fa3ed6eb60646beeb0a064350f48

These assertions assume the builds are in a specific order.  To
ensure that, wait for each build to pause before starting the next.

Change-Id: I2e62a0197b833e36522aac14dc8f4d4f386eccf5

Opendev runs a caching mirror for npm packages. Use it when running
yarn install during tox tests. Due to the way yarn.lock files work at
the moment we need to patch the lockfile on the fly to inject the
mirror urls [1]. This can be handlel inside the pip.sh where we patch
the lockfile, run yarn and reset it afterwards.

[1] https://github.com/yarnpkg/yarn/issues/2566

Change-Id: Id1f2daac8327f3110e6beeb2d6391baccfd3ce34

The tenant scoped rest api already supports enqueue, dequeue and some
others. For project admins it's also useful to be able to use promote
to push high priority changes to the front of the gate.

Change-Id: I27e06ea2fc813c6f084fd01a2e9af284d3b15b89

They are cool and they can help avoid problems like we just saw in
nodepool.  This updates to match.

Change-Id: I3191b8ba7f96151b6b9178f39bf48ededa4a00ee

This change adds a script to check if a zuul deployment is
using untrusted command on the executor host.

Operator needs to take action on the affected job to avoid
failure after upgrading to zuul v3.19.1.

Change-Id: I5d18df3fd120e8f4c189ce0b59aa89553e9df816

This adds additional reno config to tell it to scan back to the earliest
versions when we started using reno to make sure we include all notes in
the output.

It also says not to ignore null merges so that we can merge temporary
branches back into the master branch, and reno will still proceed past
the null merge.

Change-Id: I75051cd492124441befc0dff5b33ccf0442b7754
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>