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

[Fam Zheng]

> On Mar 15, 2019, at 02:22, Peter Maydell <address@hidden> wrote:
> 
> On Thu, 14 Mar 2019 at 15:57, Alex Bennée <address@hidden> wrote:
>> Testing in the Cloud
>> ====================
>> 
>> After BuildBot went out-of-service we have been relying heavily on Travis
>> as our primary CI platform. This has been creaking somewhat under the
>> strain and while we have a large test matrix its coverage is fairly
>> Ubuntu/x86 centric. However in recent months we've expanded and we now
>> have:
>> 
>>  - Shippable, cross compilers - catches a lot of 32/64 bit isms
>>  - Cirrus, FreeBSD and MacOS builds
>>  - GitLab, Alternative x86/Debian - iotests
> 
> Are any of these capable of replacing my ad-hoc collection
> of build test systems for testing merges ? I would quite like
> to be able to do that, because it would make it easier for
> other people to take over the process of handling pull requests
> when I'm away.
> 
> I think the main requirements for that would be:
> * covers full range of hosts[*]
> * can be asked to do a test build of a merge before
>   I push it to master
> * reliably completes all builds within say 90 minutes
>   of being asked to start
> 
> [+] I currently test:
> - windows crossbuilds
> - S390, AArch32, AArch64, PPC64 Linux
>   (SPARC currently disabled because of the migration-test flakiness)
> - OSX
> - FreeBSD, OpenBSD, NetBSD via the tests/vm setup
> - various x86-64 configs: from-clean; debug; clang; TCI; no-tcg;
>   linux-static (including 'make check-tcg’)

I think the gitlab CI architecture is quite capable of doing what you want 
here. Some efforts will be needed to set up the gitlab-runners in each of above 
environments and I expect tweakings will be needed to get the automation 
smooth, but it is fairly straigtforward and managable:

https://docs.gitlab.com/runner/

Fam

> 
> thanks
> -- PMM
>