Re: [PULL 00/33] Abstract ArchCPU

[Peter Maydell]

On Sun, 6 Mar 2022 at 21:13, Philippe Mathieu-Daudé
<philippe.mathieu.daude@gmail.com> wrote:
>
> +Daniel/Alex
>
> On 6/3/22 20:56, Peter Maydell wrote:
> > On Sun, 6 Mar 2022 at 19:06, Philippe Mathieu-Daudé
> > <philippe.mathieu.daude@gmail.com> wrote:
> >> I see. I only have access to aarch64 Darwin, not x86_64; I was relying
> >> on our CI for that (my GitLab CI is green). I'll work a fix, thanks.
> >
> > This was on my ad-hoc stuff -- I guess our gitlab CI for macos
> > doesn't build hvf ?
>
> No, it does:
>
> https://gitlab.com/philmd/qemu/-/jobs/2167582776#L6444
>
>    Targets and accelerators
>      KVM support                  : NO
>      HAX support                  : YES
>      HVF support                  : YES
>      WHPX support                 : NO
>      NVMM support                 : NO
>      Xen support                  : NO
>      TCG support                  : YES
>
> But the Cirrus job are allowed to fail:

Overall I am starting to feel that we should stop having
these CI jobs that are in the "allowed to fail" category.
All that happens is that they eat a lot of CPU on our CI
hosts, but they don't actually find bugs because everybody
(rightly) treats "allowed-to-fail-and-failed" as "ignore me".
I think our CI jobs should either be "must pass", or else
"run only manually", with that latter category being rarely
used and only where there's a good reason (eg somebody
specific has taken responsibility for debugging some
intermittent failure and having it still available in the
CI UI for them to trigger is helpful).

Plus we really need to get on top of all the intermittent
failures. The current state of the world is that we have
some intermittents, which makes it easy for new intermittents
to get into the tree, because everybody is in the habit of
"just hit retry"...

thanks
-- PMM