zuul/releasenotes/notes/submit-requirements-1d61f88e54be1fde.yaml
James E. Blair 7b08cb15d4 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
2023-03-28 16:19:50 -07:00

17 lines
775 B
YAML

---
fixes:
- |
Zuul will now attempt to honor Gerrit "submit requirements" when
determining whether to enqueue a change into a dependent (i.e.,
"gate") pipeline. Zuul previously honored only Gerrit's older
"submit records" feature. The new checks will avoid enqueing
changes in "gate" pipelines in the cases where Zuul can
unambiguously determine that there is no possibility of merging,
but some non-mergable changes may still be enqueued if Zuul can
not be certain whether a rule should apply or be disregarded (in
these cases, Gerrit will fail to merge the change and Zuul will
report the buildset as a MERGE_FAILURE).
This requires Gerrit version 3.5.0 or later, and Zuul to be
configured with HTTP access for Gerrit.