I merged 83920 with dependencies. Perhaps gerrit doesn't handle such chains properly (or perhaps our CI is misusing the API?). WRT current issues, posted two patches upstream: - https://gerrit.ovirt.org/#/c/83986/ - fixes the GWT build that was broken this morning, preventing a proper build altogether - https://gerrit.ovirt.org/#/c/83987/ - should fix the OST regression you noted. I'm waiting for the CI to finish running on both and will merge. On Mon, Nov 13, 2017 at 11:26 AM, Barak Korren <bkorren@redhat.com> wrote:
On 13 November 2017 at 11:10, Allon Mureinik <amureini@redhat.com> wrote:
Commit 86bf82e746404145e8b97df46f514086e4f82e69 is probably the offending commit, taking a deeper look now, should have a fix within the hour
Hmm, I see what happened there, that commit is https://gerrit.ovirt.org/c/83920, so it was tested at: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/3769 and passed.
BUT, it was tested along with https://gerrit.ovirt.org/#/c/83918/2 that was merged earlier as far as git ordering goes, but somehow was assumed to be a later patch. When we test multiple patches from the same project we essentially use packages built from the one we deem to be the latest. So in this case only the packages from 83918 were actually tested.
We went to great lengths to preserve correct patch ordering by preserving the order of event notifications reaching us from gerrit. But here it seems we ended out with out-of-order patches. Do you have any idea how did we end up with this? Do you remember what was the sequence in which you clicked the 'merge' button on the different patches?
-- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted