<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Feb 6, 2021 at 12:10 AM Jeremy Stanley <<a href="mailto:fungi@yuggoth.org">fungi@yuggoth.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2021-02-05 22:52:15 +0100 (+0100), Dmitry Tantsur wrote:<br>
[...]<br>
> 7.1. Stop marking dependent patches with Verified-2 if their<br>
> parent fails in the gate, keep them at Verified+1 (their previous<br>
> state). This is a common source of unnecessary rechecks in the<br>
> ironic land.<br>
[...]<br>
<br>
Zuul generally assumes that if a change fails tests, it's going to<br>
need to be revised.</blockquote><div><br></div><div>Very unfortunately, it's far from being the case in the ironic world.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Gerrit will absolutely refuse to allow a change<br>
to merge if its parent has been revised and the child has not been<br>
rebased onto that new revision. Revising or rebasing a change clears<br>
the Verified label and will require new test results.</blockquote><div><br></div><div>This is fair, I'm only referring to the case where the parent has to be rechecked because of a transient problem.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Which one or<br>
more of these conditions should be considered faulty? I'm guessing<br>
you're going to say it's the first one, that we shouldn't assume<br>
just because a change fails tests that means it needs to be fixed.<br></blockquote><div><br></div><div>Unfortunately, yes.</div><div><br></div><div>A parallel proposal, that has been rejected numerous times, is to allow recheching only the failed jobs.</div><div><br></div><div>Dmitry<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
This takes us back to the other subthread, wherein we entertain the<br>
notion that if changes have failing jobs and the changes themselves<br>
aren't at fault, then we should accept this as commonplace and lower<br>
our expectations.<br>
<br>
Keep in mind that the primary source of pain here is one OpenStack<br>
has chosen. That is, the "clean check" requirement that a change get<br>
a +1 test result in the check pipeline before it can enter the gate<br>
pipeline. This is an arbitrary pipeline criterion, chosen to keep<br>
problematic changes from getting approved and making their way<br>
through the gate queue like a wrecking-ball, causing repeated test<br>
resets for the changes after them until they reach the front and<br>
Zuul is finally able to determine they're not just conflicting with<br>
other changes ahead. If a major pain for Ironic and other OpenStack<br>
projects is the need to revisit the check pipeline after a gate<br>
failure, that can be alleviated by dropping the clean check<br>
requirement.<br>
<br>
Without clean check, a change which got a -2 in the gate could<br>
simply be enqueued directly back to the gate again. This is how it<br>
works in our other Zuul tenants. But the reason OpenStack started<br>
enforcing it is that reviewers couldn't be bothered to confirm<br>
changes really were reasonable, had *recent* passing check results,<br>
and confirmed that observed job failures were truly unrelated to the<br>
changes themselves.<br>
-- <br>
Jeremy Stanley<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Red Hat GmbH, <a href="https://de.redhat.com/" target="_blank">https://de.redhat.com/</a> , Registered seat: Grasbrunn, <br>Commercial register: Amtsgericht Muenchen, HRB 153243,<br>Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill <br></div></div></div>