GSoC 2022 CI project idea proposal

Andrea Bolognani abologna at redhat.com
Fri Feb 25 13:49:39 UTC 2022


On Fri, Feb 25, 2022 at 12:30:08PM +0100, Erik Skultety wrote:
> On Fri, Feb 25, 2022 at 03:02:49AM -0800, Andrea Bolognani wrote:
> > Do you have any high-level concerns about the ci/build approach I
> > vaguely described? The finer details are of course far from being set
> > in stone, but I think the overall idea is solid and we should aim for
> > it being implemented as we evolve our CI tooling.
>
> No, I think that was a solid proposal, I would probably think of along those
> lines as well had I ever come to that idea myself :).
> Having each repo define their own build script which can be consumed both
> during local test executions and copied to the Dockerfile for a gitlab job to
> consume makes complete sense.

Just to make sure we're on the same page, what do you mean by "copied
to the Dockerfile"? The CI job can call the script directly from the
local clone of the repository just like a developer would on their
machine - no copying necessary. The Dockerfile describes the
environment a build will happen in, not the build steps.

> Top it off with something like 'lcitool container --script
> <path_to_build_script>' and I think we have a solid ground for future work.

We're stepping into premature bikeshedding territory here :) but I
would expect this to look like 'lcitool build $target --container' or
something along those lines.

Making it possible to specify an alternate path to the build script
could be a neat feature, but we should have a sensible default that
makes it possible for people to simply not care most of the time.

-- 
Andrea Bolognani / Red Hat / Virtualization




More information about the libvir-list mailing list