Open Stack

On 2021-02-05 22:52:15 +0100 (+0100), Dmitry Tantsur wrote:
[...]
> 7.1. Stop marking dependent patches with Verified-2 if their
> parent fails in the gate, keep them at Verified+1 (their previous
> state). This is a common source of unnecessary rechecks in the
> ironic land.
[...]

Zuul generally assumes that if a change fails tests, it's going to
need to be revised. Gerrit will absolutely refuse to allow a change
to merge if its parent has been revised and the child has not been
rebased onto that new revision. Revising or rebasing a change clears
the Verified label and will require new test results. Which one or
more of these conditions should be considered faulty? I'm guessing
you're going to say it's the first one, that we shouldn't assume
just because a change fails tests that means it needs to be fixed.
This takes us back to the other subthread, wherein we entertain the
notion that if changes have failing jobs and the changes themselves
aren't at fault, then we should accept this as commonplace and lower
our expectations.

Keep in mind that the primary source of pain here is one OpenStack
has chosen. That is, the "clean check" requirement that a change get
a +1 test result in the check pipeline before it can enter the gate
pipeline. This is an arbitrary pipeline criterion, chosen to keep
problematic changes from getting approved and making their way
through the gate queue like a wrecking-ball, causing repeated test
resets for the changes after them until they reach the front and
Zuul is finally able to determine they're not just conflicting with
other changes ahead. If a major pain for Ironic and other OpenStack
projects is the need to revisit the check pipeline after a gate
failure, that can be alleviated by dropping the clean check
requirement.

Without clean check, a change which got a -2 in the gate could
simply be enqueued directly back to the gate again. This is how it
works in our other Zuul tenants. But the reason OpenStack started
enforcing it is that reviewers couldn't be bothered to confirm
changes really were reasonable, had *recent* passing check results,
and confirmed that observed job failures were truly unrelated to the
changes themselves.
-- 
Jeremy Stanley
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210205/cb354e3f/attachment.sig>