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

[Alex Bennée]

Peter Maydell <address@hidden> writes:

> 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.

Not necessarily. The build runner is just a daemon on the build machine
so there is nothing that stops is ssh'ing into our own infrastructure
and re-running the test from the command line. Of course in the ideal
case test failures occurring in CI should be able to be replicated in a
normal source checkout.

--
Alex Bennée