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.
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
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
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.
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).
As discussed in , create a job that will check that a release request
has been approved by the PTL or a release liaison attached to the
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).