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

["Daniel P. Berrangé" <berrange@redhat.com>]

On Fri, Oct 18, 2024 at 11:28:53AM -0300, Fabiano Rosas wrote:
> Daniel P. Berrangé <berrange@redhat.com> writes:
> 
> > On Fri, Oct 18, 2024 at 10:51:03AM -0300, Fabiano Rosas wrote:
> >> Daniel P. Berrangé <berrange@redhat.com> writes:
> >> 
> >> > 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 ?
> >> 
> >> What do you mean by distinct programs? It's not the migration-test that
> >> decides on which targets it runs, it's meson.build. We register a test()
> >> for each target, same as with any other qtest. Maybe I misunderstood
> >> you...
> >
> > If we split, we could have meson.build register "migration-smoketest"
> > for every target while registering "migration-bigtest" for just 1 target.
> 
> Isn't that a bunch of shuffling code around just to have two different
> invocations of migration-test?

Yes, pretty much, but that's not an inherantly bad thing. Migration
is a bit of an outlier in its attempt to test the entire subsystem
from a single test binary.

> There's the possibility of using the gtester path like
> /x86_64/migration/smoke and passing '-r' when invoking via meson. That
> requires way fewer changes in the C code. It moves the complexity into
> meson.build, which might be worse.
> 
> Alex's idea of full set for KVM arch + a TCG arch would probably be
> trickier in meson.

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 :|