Re: [PATCH] qga: Allow building of the guest agent without system emulators or tools

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

On Thu, Nov 10, 2022 at 10:57:27AM +0100, Thomas Huth wrote:
> On 10/11/2022 10.49, Philippe Mathieu-Daudé wrote:
> > On 10/11/22 09:35, Thomas Huth wrote:
> > > On 10/11/2022 06.49, Markus Armbruster wrote:
> > > > Philippe Mathieu-Daudé <philmd@linaro.org> writes:
> > > > 
> > > > > On 9/11/22 18:37, Thomas Huth wrote:
> > > > > > If configuring with "--disable-system --disable-user --enable-guest-agent"
> > > > > > the linking currently fails with:
> > > > > > 
> > > > > > qga/qemu-ga.p/commands.c.o: In function `qmp_command_info':
> > > > > > build/../../home/thuth/devel/qemu/qga/commands.c:70:
> > > > > > undefined reference to `qmp_command_name'
> > 
> > > > > > Let's make sure that we also compile and link the required files if
> > > > > > the system emulators have not been enabled.
> > > > > > 
> > > > > > Signed-off-by: Thomas Huth <thuth@redhat.com>
> > > > 
> > > > I wonder for how long this has been broken.
> > > > 
> > > > Should we add such a configuration to CI?
> > > 
> > > Some month ago, I'd say: Sure! ... but considering that gitlab now
> > > limits the available CI minutes and that apparently nobody really
> > > cares about this configuration (otherwise someone would have
> > > complained about this earlier), I think it's not that important to
> > > have a separate CI test for this configuration.
> > 
> > We could eventually add a job restricted to qemu-project CI (not in
> > forks).
> 
> The problem is: Who's going to create such jobs? Someone needs to write the
> yaml stuff and test it first. And at least I pretty much lost motivation to
> work on new yaml stuff, since this burns my private CI minutes (which I
> rather need for my maintainer duties instead).

Top tip: if you're working on GitLab CI changes, create a separate
QEMU fork in a different namespace for your adhoc testing, separate
from your normal maintainer work.

CI minutes are limited per namespace, ie group or user account, and
AFAIK, there is no limit on the number of groups you can create.

eg, create a group called /thuth-ci, and fork QEMU into that and
you've doubled the number of CI minutes available, so you can afford
to mess around with CI changes and not risk ability to do your other
normal work.

Now of course this ability to create many groups can be abused and
I expect GitLab would take a dim view of such abuse. So I would only
use this creation of extra groups for this very specific use case of
needing to battle test CI YAML changes.

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