diff options
author | James E. Blair <jim@acmegating.com> | 2023-03-27 15:34:46 -0700 |
---|---|---|
committer | James E. Blair <jim@acmegating.com> | 2023-03-28 16:19:50 -0700 |
commit | 7b08cb15d4a8baf50678fb99f442c397d863b1b7 (patch) | |
tree | 6ea87a06dfa27cd523fae5ea44baee9f1ec01172 /releasenotes/notes/resource-usage-stats-bfcd6765ef4a9c86.yaml | |
parent | 8ebab861c54534efc8ee3b1de7d065f1848576bf (diff) | |
download | zuul-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 'releasenotes/notes/resource-usage-stats-bfcd6765ef4a9c86.yaml')
0 files changed, 0 insertions, 0 deletions