Porting this test needed some fundamental help because we haven't had
any tests that required changing the tenant config before.
Change-Id: Ife0bf391340d24f33b516afdb24626415ad7d65f
Story: 2001134
Task: 4847
After upgrading Gerrit to 2.13 our gate stopped working. The reason
for this is that after a successful gate run zuul does something like
'gerrit review --label verified=2 --submit'. The verified label in
Gerrit by default is configured as 'Verified'. The newer version of
gerrit behaves different now. It accepts the +2 vote on verified but
doesn't submit the patch anymore if the casing is not correct. This
forces us to specify the label in the same casing as gerrit
expects. In that case the tolower() in canMerge prevents the patch
from entering the gate.
In order to avoid confusion and be consistent, avoid any case
conversions and use the labels exactly as defined in Gerrit.
Note that this patch requires changes to the pipelines such that the
labels are spelled exactly as defined in Gerrit.
Change-Id: I9713a075e07b268e4f2620c0862c128158283c7c
Allows multiple reports per a patchset to be sent to pluggable
destinations. These are configurable per pipeline and, if not
specified, defaults to the legacy behaviour of reporting back only
to gerrit.
Having multiple reporting methods means only certain success/failure
/start parameters will apply to certain reporters. Reporters are
listed as keys under each of those actions.
This means that each key under success/failure/start is a reporter and the
dictionaries under those are sent to the reporter to deal with.
Change-Id: I80d7539772e1485d5880132f22e55751b25ec198
Add the ability for Zuul to accept inputs from multiple trigger
sources simultaneously.
Pipelines are associated with exactly one trigger, which must now
be named in the configuration file.
Co-Authored-By: Monty Taylor <mordred@inaugust.com>
Change-Id: Ief2b31a7b8d85d30817f2747c1e2635f71ea24b9
Now that live reconfiguration is an option, we sometimes load the
Zuul config before the remote repo is created. To handle that,
gracefully handle that case when the Repo object is created by the
Merger. Keep track of whether the initial clone has happened, and
check for that before every local Repo operation. If we get an
event that involves a repo before it exists (unlikely!) that will
still error and raise an exception (that should be caught higher
up in the stack).
Add a test for this case.
In the test suite, when adding a fake change to the upstream repo,
always reset it so that HEAD is master so that new repos clone
from a consistent state.
Also remove an errant assertEmptyQueues because it's handled by
assertFinalState.
Change-Id: Ic6eec83e3faa2a15be4b23d4cfcfbddcac82983c
Clint Byrum