Peter Maydell <peter.mayd...@linaro.org> writes:
> On Fri, 15 Mar 2019 at 09:05, Alex Bennée <alex.ben...@linaro.org> wrote: >> >> >> Peter Maydell <peter.mayd...@linaro.org> 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
