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.
This is a backport of I9713a075e07b268e4f2620c0862c128158283c7c to
master.
Change-Id: I55e6f12969c1c920a5017382523e71e12bc7ac3c
In the case of a post-merge pipeline (ie, one that
responds to ref-updated events) this increases the accuracy of
a multi-repo checkout by consulting the zuul merger when
cloning and updating the project in question. All other projects
are updated from the upstream git url. Previously all repos would
be cloned and updated from the upstream url. That is normally
fine, but in some cases they may actually lag behind, but the
merger will have the most current copy of the repo for the project
in question.
This is safe because we now ensure that mergers fully update the
branches and tags of their local copies.
The assertion in test_cache_dir is updated to reflict this change.
Its intent is to verify that the origin in a prepared repo is not
the cache (that would be detrimental since the cache will never
update). It did this by asserting that the origin was the upstream
url. However, with this change the origin may be the zuul_url (and
should be for project1 in this test). So the assertion is changed
to verify that the origin is the zuul url. A second assertion that
it is also not the cache is added for clarity and extra protection.
This test conveniently also tests cloning a repo which is not the
zuul_project, so add the original assertion back but modified for
that project. This way both variants are now tested.
Change-Id: If22d8cfbe591afe4f5516da1eb3b0be98b2de874
When a merger gets a request to update a repo for anything other
than a pre-merge job (eg, ref-updated, periodic, etc), it simply
updates the repository from upstream. While it did update its
tags and remote branch references, it did not actually update
its local branch heads. Switch to using the 'reset' method
so that happens (along with the update which was already happening).
This corrects a situation where a periodic or post job might pull
data from a repo on a zuul merger and end up with out of date
information.
Change-Id: Iccc691974ae5efedec9bfa5b553b451a1b5ab686
This is the 'test_grenade_forward' and 'test_upgrade_backward'
tests from d-g. Both scenarios are covered because they both
simulate havana->master upgrades, just changing which of them
is the 'current' change. Since we examine the states of all
changes, in the course of running the test we check the results
for both when a current change is havana and master.
This also covers the 'test_branch_override' case from d-g.
Change-Id: I95abd62279bd44e88a608ad908f4876d11d50ec2
The cloner takes an argument for the "indicated branch", however,
that argument has a default value of None, rendering it optional.
In the original setup method from devstack gate, that argument
was not optional, instead, it was typically set to ZUUL_BRANCH
unless it needed to be specified otherwise, for example for grenade.
Effectively, if omitted the (optional) branch argument to the cloner
it would use the 'master' branch in preference to the ZUUL_BRANCH
for projects that do not have a zuul ref. This is not the desired
behavior in the simple case (or quite likely any case), and therefore
should not be the default behavior for the cloner.
Resolve this by having the cloner treat the indicated branch as
ZUUL_BRANCH unless it is specified in the branch argument. In doing
this, the logic in the cloner is slightly simplified and now more
closely matches that in the setup_project function in devstack-gate.
Rename the cloner test to 'test_one_branch' to match the pattern from
devstack-gate tests. This test encompases the 'test_one_on_master'
and 'test_two_on_master' tests from d-g. They are combined because
in these tests we are able to iterate over the Zuul builds and check
the state for each build in turn, which is a more complete form of
testing than what was employed in d-g.
Add the 'test_multi_branch' test to the cloner. This encompases
'test_multi_branch_on_master' (with an additional fourth project
with no changes), as well as 'test_multi_branch_on_stable'.
Change-Id: Ib26bced46073bd61298c52c836a20085511201f3
Tobias Henkel