GSoC 2022 CI project idea proposal

[Daniel P. Berrangé]

On Fri, Feb 25, 2022 at 08:36:10AM -0800, Andrea Bolognani wrote:
> On Fri, Feb 25, 2022 at 02:09:13PM +0000, Daniel P. Berrangé wrote:
> > I've never got on very well with the 'lcitool build' command as its
> > a bit of a black box you don't have much control over. In its current
> > impl, it also means that lcitool has to know about build commands for
> > each project which is unfortunate.
> 
> My proposal to standardize on running a ci/build script that's
> maintained as part of the project itself, and that is also used for
> the regular CI jobs, would address this.
> 
> > If we're going to wire up support for containers, I think we should
> > start by just creating a 'lcitool run $target-or-host' command that
> > brings up an environment with an interactive shell, with the current
> > source present. eg
> >
> >    $ lcitool run fedora-35
> 
> This becomes a lot of fun when you start considering how to have a
> consistent interface across containers and VMs. Exposing the local
> git tree to a container is sort of easy (even though there are a
> number of caveats) but to achieve the same result with a VM you'd
> need to get something like virtiofs involved and coordinate with the
> guest OS in non trivial ways...
> 
> > We could then let it take a command + args to run as extra args
> >
> > eg
> >
> >    $ lcitool run fedora-35 meson build
> >    $ lcitool run fedora-35 ninja -C build
> >
> > would just work with VM, but for containers you would need the
> > container FS to be persistent across runs. This could be achieved
> > by giving the container an explicit name, so you just re-restart
> > the same container each time instead of using a throwaway container.
> >
> > The basic idea though is that running stuff inside the container/VM
> > is just the same as running stuff in your local checkout. The exact
> > same command name(s0, just prefixed with 'lcitool run fedora-35'.
> >
> > Or in my case I'd add an alias
> >
> >    alias f35='lcitool run fedora-35'
> >
> > so i can do
> >
> >   $ f35 meson build
> >   $ f35 ninja -C bujld
> 
> If you're trying to reproduce a CI failure locally so that you can
> debug it, or performing validation before posting patches, you don't
> want to spell out the build steps this way. What you want is to call
> 
>   $ lcitool build fedora-35 --container
> 
> and get the same failure you've seen in the CI pipeline, because the
> same steps have been executed in the same container image.

I guess that depends on your POV really, as that's not the way
I prefer to debug things.  I want to have an interactive shell
and invokes the individual commands myself, so that I can
have ability to customize their invokation to alter loggging
or debugging settings, or choose different build options to
understand their effect.

IOW, what matters to me is the getting an environment up and
running, with the source tree available, and ready to step
through the build commands.  A 'ci/build' shell script is
ok to just reproduce a failure, but since it doesn't let me
tweak things, I'm not likely to use it much for debugging.

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