Re: [Qemu-devel] State of QEMU CI as we enter 4.0

[Peter Maydell]

On Fri, 15 Mar 2019 at 09:05, Alex Bennée <address@hidden> wrote:
>
>
> Peter Maydell <address@hidden> writes:
> > [+] I currently test:
> >  - windows crossbuilds
>
> We did have this with shippable but had to disable it when the upstream
> repo went down. We could re-enable if we can rebuild it and cache our
> docker images with Daniel's work.
>
> >  - S390, AArch32, AArch64, PPC64 Linux
> >    (SPARC currently disabled because of the migration-test flakiness)
>
> We would need to get machines from somewhere. Setting up a headless
> SynQuacer should be easy enough and we have qemu-test which is a
> ThunderX beast. I guess the IBM guys would have to chime in if they
> could find PPC/s390 boxen because I'm guessing spamming the GCC build
> farm with our test runners would be a little unfair.

For S390x we have a just-for-QEMU machine already, courtesy of IBM.
We're already doing builds on the GCC build farm machines, so
as long as we don't increase the number of things we're building
that way (ie we don't allow them to be used by random other
submaintainers doing test runs) I don't think it should increase
the load on them. We should definitely check with the cfarm admins
on how allowable buildbot-equivalents are, though. And as you say
with our Linaro hats on we can provide the Arm hosts, so it's just
PPC and SPARC. I should also mention MIPS here which is not in
my set of host builds because I've never found a MIPS box fast
enough.

> >  - FreeBSD, OpenBSD, NetBSD via the tests/vm setup
>
> We build on FreeBSD on Cirrus - but any x86 box can run the test/vm
> setup assuming your just kicking it off with a make vm-test type thing?

Yep.

> >  - various x86-64 configs: from-clean; debug; clang; TCI; no-tcg;
> >    linux-static (including 'make check-tcg')
>
> This is already covered in our rather large Travis matrix. The trick
> will be making it all fast enough.

Yes; Travis build time is at least twice the elapsed-time we are
looking for here.

The other nice part about my current setup is that if something
fails on a random odd host architecture I can just ssh in and
run the test by hand to debug it. I'm guessing that any of this
sort of CI setup is going to prohibit that.

thanks
-- PMM