GSoC 2022 CI project idea proposal

[Andrea Bolognani]

On Fri, Feb 25, 2022 at 05:14:41PM +0000, Daniel P. Berrangé wrote:
> On Fri, Feb 25, 2022 at 08:36:10AM -0800, Andrea Bolognani wrote:
> > 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.

As long as you still have the ability to use 'lcitool shell' to enter
the environment, your use case should be covered. I agree that we
should have that ability, and in fact the ci/helper script already
supports it.

What I'm trying to say is that getting

  $ lcitool run fedora-35 meson build
  $ lcitool run fedora-35 ninja -C build

to work as expected is much harder than enabling

  $ lcitool shell fedora-35
  > meson build
  > ninja -C build

because the former needs persistence across lcitool runs while the
latter doesn't.

-- 
Andrea Bolognani / Red Hat / Virtualization