qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Cédric Le Goater
Subject: Re: Getting rid of the last bits of QEMU's 'ad-hoc CI' for merges
Date: Mon, 16 May 2022 15:51:15 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0

On 5/16/22 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 :-))

No recent HW (P8 and above) would run a PPC64 BE distro if LE is
supported by HW.
The only BE-only HW would be a G5 (970) or a P7 (with OPAL).
These are really scarce now and I doubt they would be accessible
for external jobs.

The simplest would be to run a pseries KVM guest or PowerVM LPAR
with a debian sid, which still supports BE. Where is the question.

C.


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

thanks
-- PMM





reply via email to

[Prev in Thread] Current Thread [Next in Thread]