On Fri, 4 Mar 2022 at 17:41, Paolo Bonzini <pbonz...@redhat.com> wrote: > The test seems to be flaky, I've been fighting with it all week---trying > multiple versions of this pull request and removing patches until > build-oss-fuzz passed. The set of patches that triggered it or not was > completely random, but I'll not that it did pass with this exact commit > I'm submitting (https://gitlab.com/bonzini/qemu/-/jobs/2154365356). > > I wanted to look at this today again before replying to you, but as you > know I was sidetracked by work on the qemu.org infrastructure. So, I > can look at this but I really need to ask you one of two favors: > > 1) decide that the test is flaky and merge this pull request, and then > I'll send before Monday the changes that I've omitted here (which again > have nothing to do with qos-test). I'll look at qos-test during soft > freeze. > > 2) accept that I'll send another x86 pull request (not a large one) > after soft freeze, so that I have more time to debug this (likely > unrelated) build-oss-fuzz issue.
Either of these is fine; my requirement is only that either: (1) the oss-fuzz gitlab CI job needs to in practice actually pass at least most of the time (2) we need to switch it to ok-to-fail or disable it so I don't have CI failing for every merge I make. We seem to have several intermittents right now (including one which makes oss-fuzz hang, I think) which I'll try to find time to investigate soon. Plus the CI infra in general is flaky: some of the intermittents are clearly gitlab issues (like failing to manage to git clone things). thanks -- PMM
