summaryrefslogtreecommitdiff
path: root/Dockerfile
diff options
context:
space:
mode:
authorJames E. Blair <jim@acmegating.com>2023-03-27 15:34:46 -0700
committerJames E. Blair <jim@acmegating.com>2023-03-28 16:19:50 -0700
commit7b08cb15d4a8baf50678fb99f442c397d863b1b7 (patch)
tree6ea87a06dfa27cd523fae5ea44baee9f1ec01172 /Dockerfile
parent8ebab861c54534efc8ee3b1de7d065f1848576bf (diff)
downloadzuul-7b08cb15d4a8baf50678fb99f442c397d863b1b7.tar.gz
Check Gerrit submit requirements
With newer versions of Gerrit, we are increasingly likely to encounter systems where the traditional label requirements are minimized in favor of the new submit requirements rules. If Gerrit is configured to use a submit requirement instead of a traditional label blocking rule, that is typically done by switching the label function to "NoBlock", which, like the "NoOp" function, will still cause the label to appear in the "submit_record" field, but with a value of "MAY" instead of "OK", "NEED", or "REJECT". Instead, the interesting information will be in the "submit_requirements" field. In this field we can see the individual submit requirement rules and whether they are satisfied or not. Since submit requirements do not have a 1:1 mapping with labels, determining whether an "UNSATISFIED" submit requirement should be ignored (because it pertains to a label that Zuul will alter, like "Verified") is not as straightforward is it is for submit records. To be conservative, this change looks for any of the "allow needs" labels (typically "Verified") in each unsatisfied submit record and if it finds one, it ignores that record. With this change in place, we can avoid enqueing changes which we are certain can not be merged into gate pipelines, and will continue to enqueue changes about which we are uncertain. Change-Id: I667181565684d97c1d036e2db6193dc606c76c57
Diffstat (limited to 'Dockerfile')
0 files changed, 0 insertions, 0 deletions