From: "Daniel P. Berrangé" <berrange@redhat.com>
To: "Alex Bennée" <alex.bennee@linaro.org>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
"QEMU Developers" <qemu-devel@nongnu.org>,
"Richard Henderson" <richard.henderson@linaro.org>,
"Kevin Wolf" <kwolf@redhat.com>, "John Snow" <jsnow@redhat.com>,
"Philippe Mathieu-Daudé" <philmd@linaro.org>
Subject: Re: no more pullreq processing til February
Date: Thu, 26 Jan 2023 14:35:36 +0000 [thread overview]
Message-ID: <Y9KPuOT3NEAjN740@redhat.com> (raw)
In-Reply-To: <87pmb1pfas.fsf@linaro.org>
On Thu, Jan 26, 2023 at 01:57:02PM +0000, Alex Bennée wrote:
>
> Peter Maydell <peter.maydell@linaro.org> writes:
>
> > Hi; we've run out of gitlab CI pipeline minutes for this month.
> > This leaves us the choice of:
> > (a) don't process any more pullreqs til we get more minutes in Feb
> > (b) merge pullreqs blindly without CI testing
> > (c) buy more minutes
> >
> > For the moment I propose to take option (a). My mail filter will
> > continue to track pullreqs that get sent to the list, but I won't
> > do anything with them.
> >
> > If anybody has a better suggestion feel free :-)
>
> I've submitted a support request (#366644) to GitLab to see if they will
> give us more minutes for this month. Longer term ideas:
>
> * Reduce compile time by reducing number of identical object files we
> build for specific_ss
> * Move more tests over to custom runners (don't we have an x86 box
> somewhere?)
NB, we don't want to sacrifice coverage for contributors fork CI.
The current private runners don't do that because they're testing
scenarios that were already impossible with shared runners.
> * Carry out an audit of code coverage for different test sets and
> rationalise our CI set
I'm confident we can rationalize our jobs, especially the cross
compilation ones.
For each non-x86 arch we've got two sets of jobs, one for system
emulators and one for user emulators.
IMHO the most interesting part of non-x86 testing is the TCG
host target. We don't need 2 jobs to cover that, either system
or user emulators would cover TCG build / test. Most of the rest
of code is not heavily host arch dependant.
So for cross compilation we could limit ourselves to
- 1 job per TCG host target
- Some full coverage job(s) for a big endian arch
- Some full coverage job(s) for a 32-bit arch
I expect that could eliminate quite a few cross arch jobs.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
next prev parent reply other threads:[~2023-01-26 14:36 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-26 13:22 no more pullreq processing til February Peter Maydell
2023-01-26 13:52 ` Eldon Stegall
2023-01-26 14:13 ` Alex Bennée
2023-01-26 14:27 ` Peter Maydell
2023-01-26 14:38 ` Daniel P. Berrangé
2023-01-26 18:41 ` Eldon Stegall
2023-01-27 9:53 ` Daniel P. Berrangé
2023-01-26 14:18 ` Daniel P. Berrangé
2023-01-26 14:30 ` Daniel P. Berrangé
2023-01-27 8:50 ` Gerd Hoffmann
2023-01-26 13:57 ` Alex Bennée
2023-01-26 14:07 ` Daniel Henrique Barboza
2023-01-26 14:27 ` Daniel P. Berrangé
2023-01-26 14:35 ` Daniel P. Berrangé [this message]
2023-01-26 14:41 ` Peter Maydell
2023-01-26 18:17 ` Thomas Huth
2023-01-26 20:49 ` Alex Bennée
2023-01-26 14:25 ` Stefan Hajnoczi
2023-01-26 14:28 ` Peter Maydell
2023-01-27 7:36 ` Thomas Huth
2023-01-27 12:39 ` Kevin Wolf
2023-01-27 12:47 ` Daniel P. Berrangé
2023-01-27 13:11 ` Peter Maydell
2023-01-27 13:12 ` Peter Maydell
2023-02-01 16:18 ` Peter Maydell
2023-01-27 9:30 ` Markus Armbruster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y9KPuOT3NEAjN740@redhat.com \
--to=berrange@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=philmd@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=richard.henderson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.