Re: Getting rid of the last bits of QEMU's 'ad-hoc CI' for merges

[Thomas Huth <thuth@redhat.com>]

On 16/05/2022 14.43, Peter Maydell wrote:
> We've made pretty good progress on transitioning our pre-merge CI
> from running ad-hoc on machines the person doing the merge has access to
> to all CI being driven by the Gitlab CI infrastructure. For this (7.1) release
> cycle I think ideally we should try to get rid of the last few bits
> of ad-hoc CI so that for 7.2 we are using only the gitlab CI. (This
> will help in handing over merge request management to Stefan for 7.2.)
> 
> I think the last setups I have been using ad-hoc scripting for are:
> 
> (1) PPC64 big-endian Linux
> (2) NetBSD (x86)
> (3) OpenBSD (x86)
> 
> I think we can get away with just dropping ppc64be -- we have
> coverage for it as a cross-compile setup, and hopefully the
> s390x CI runner will catch the various "fails tests on big-endian host"
> issues. (Alternatively if anybody has a ppc64be machine they'd like
> to let us run a gitlab CI runner on, we could do that :-))

Ack, that should cover most scenarios already. (tcg backend is the only one 
that would not get any coverage anymore)

> For the BSDs, the ad-hoc CI is just running the tests/vm
> "make vm-build-netbsd" etc. Is there some way we can get
> coverage of this into the gitlab CI setup? (I think we
> have FreeBSD via Cirrus CI, so I have not listed that one.)

A simple setup is already there, running NetBSD and OpenBSD via KVM on the 
Cirrus-CI, see e.g.:

  https://gitlab.com/thuth/qemu/-/jobs/2411943817#L1973

Caveats:
- The jobs are currently marked as "manual only" since the double
   indirect setup (via cirrus-run and KVM) is not that reliable.
   Also we can not run that many cirrus-ci jobs in parallel, so
   we likely don't want to enable these by default.
- Compilation is not very fast, the jobs often run longer than
   1h, though the --target-list is very short already.

Anyway, this should show that running NetBSD and OpenBSD is very well 
possible in our CI - we just need a more powerful x86 host with KVM enabled 
for this.

  Thomas