The check-release-approval job currently considers a change being
approved if a release liaison is the change owner, or if a release
liaison approves it in a subsequent vote.
This means that if a release liaison pushes the original change (and
is therefore the change owner), any patchset pushed above the original
one will retain the owner and therefore the approval.
Instead of the change owner, use the committer of the last revision.
Change-Id: I2f7730626a8785b63f88fdf5d507fbd97717b8f3
When no review is posted yet, Gerrit returns simplified 'labels'
data. In particular it's missing the ['labels']['Code-Review]['all']
dictionary, which we assumed would always be present.
We should only add approvers from the reviews if the 'all' key is
provided, and otherwise just work from the owner email.
Remove all changes pushed to investigate the issue: use a narrow
query again (rather than the /detail call) and no longer catch the
exception.
Change-Id: I13fa07754e38281c63dcf0eceaa4c3b3c2715618
Gerrit sometimes returns a partial JSON answer, missing
the details that o=DETAILED_LABELS should trigger. This
results in false negatives in check-release-approval tests.
This cannot be reproduced easily. We put in place a retry
but the issue seems to stick on immediate retries.
As an experiment, this change switches the API call from
/changes/ID with o=DETAILED_LABELS&o=DETAILED_ACCOUNTS to
/changes/ID/detail (which includes these two options, amongst
others), to see if that would workaround the Gerrit issue.
We also remove the retry since it does not improve significantly
the situation.
Change-Id: I4de49da1b48f7b87879102a0e18e97168e39406b
We've had a number of occurrences where Gerrit failed to return a
complete JSON answer. In particular, the ['labels']['CodeReview']['all']
content is not provided, while the query requires o=DETAILED_LABELS.
Since this is a rare occurrence (which could not be reproduced on
manual testing) let's retry once to load the results from Gerrit.
Change-Id: I98d1010e9586d2329137d5d600c66eeb8343fa97
We've had hard-to-track exceptions with missing keys in Gerrit
query answers. Let's log the JSON in case of KeyError parsing
Gerrit response.
Change-Id: I495c225022250f9fa055c12c422071b1f42ff753
Limit check-release-approval to openstack/releases since no
other repository should be using it.
Also fix a corner case where release requests combined with
other changes would crash the check code (only changes in
deliverable files should be taken into account).
Change-Id: I2d744c1d4dfe13a795c0d6754520d1bbf39162b5
As discussed in [1], create a job that will check that a release request
has been approved by the PTL or a release liaison attached to the
deliverable.
Since this job is very short and will be rerun every time a vote is
posted, rather than consume a remote host, it will be run directly on
the executor. To that effect, the python script called only uses stdlib
or modules that are already present on the executor (requests and yaml).
[1] http://lists.openstack.org/pipermail/openstack-infra/2019-December/006556.html
Change-Id: Ibe1f0fba6ae2a459be22b33d8de4285b739a1df0
Thierry Carrez