Re: [PATCH 4/4] ci: Add check-migration-quick to the clang job

["Alex Bennée" <alex.bennee@linaro.org>]

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Fri, Oct 18, 2024 at 10:46:55AM +0100, Peter Maydell wrote:
>> On Fri, 18 Oct 2024 at 10:01, Daniel P. Berrangé <berrange@redhat.com> wrote:
>> >
>> > On Thu, Oct 17, 2024 at 01:29:35PM -0300, Fabiano Rosas wrote:
>> > > Daniel P. Berrangé <berrange@redhat.com> writes:
>> > >
>> > > > On Thu, Oct 17, 2024 at 11:32:11AM -0300, Fabiano Rosas wrote:
<snip>
>
> Migration-test *used* to take 15 minutes to run, but that was a
> very long time ago. A run of it today is around 1m20.
>
> That said, if you are building multiple system emulators, we
> run the same test multiple times, and with the number of
> targets we have, that will be painful.

I think this is the main problem. We run the whole set of tests for
every system emulator we build and I doubt we are actually increasing
any coverage. One suggestion I made previously was to change the test
selection logic so we only run all the tests for the KVM target and one
TCG target. For the other targets we should run the basic tests only to
ensure there is now architecture specific breakage for migration
generally.

> That could be a good reason to split the migration-test into
> two distinct programs. One program that runs for every target,
> and one that is only run once, for some arbitrary "primary"
> target ?  Or could we make use of glib's g_test_thorough
> for this - a primary target runs with "SPEED=through" and
> all other targets with normal settings. That would give us
> a way to optimize any of the qtests to reduce redundant
> testing where appropriate.

Does splitting the tests make it easier? Would meson just pick which
arches for the "migrtion-full" experience?

My idea was just to pass the list of configured builds as an environment
variable and without it default to everything. That way running the test
by hand would still have full coverage.

>
>
> If we move alot of testing out into a migration unit test,
> this also solves the redundancy problem.
>
>
> With regards,
> Daniel

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro