[libvirt PATCH 00/20] ci: Move GitLab build recipes to a standalone script

[Erik Skultety]

On Tue, Feb 14, 2023 at 02:31:26PM +0000, Daniel P. Berrangé wrote:
> On Mon, Feb 06, 2023 at 03:45:12PM +0000, Daniel P. Berrangé wrote:
> > On Mon, Feb 06, 2023 at 02:52:57PM +0100, Erik Skultety wrote:
> > I appreciate the goal of being able to run CI commands locally, but
> > I'm not feeling this approach is a net win. I'd much rather just
> > having developers invoke the meson command directly, which is not
> > that hard.
> > 
> > If we do really want to provide something that 100% mirrors the
> > gitlab CI job commands though, I'm even more convinced now that
> > we should be using the .gitlab-ci.yml as the canonical source.
> > 
> > Since I last mentioned that idea, I found out that this should
> > be something we can achieve via the gitlab runner 'exec' command.
> 
> I wonder if we've been thinking about this from the wrong angle.
> 
> We've been looking at the problem of "we have a gitlab-ci.yml" and
> we want to be able to locally run the jobs it defines. This creates
> us the problem of interpreting the gitlab-ci.yml file, which is
> very hard.
> 
> 95% of what we define in the gitlab-ci.yml file comes in via the
> includes of ci/gitlab.yml which is entirely auto-generated from
> our ci/manifest.yml file. 
> 
> IOW, can we rephase the problem to "we have a ci/manifest.yml" and
> we want to locally run the jobs it implies. We already have the
> code for parsing the ci/manifest.yml file, and so (mostly) know
> what jobs we expect to have.
> 
> What we're missing is the project specific build rules which
> still live in the hand crafted .gitlab-ci.yml.
> 
> If we could get the project specific build rules to be expressed
> in the ci/manifest.yml file,  then we have all the info we need
> to be able to run jobs locally. We could then make even the root
> .gitlab-ci.yml be auto-generated, which would be nice.

Honestly ^this to me sounds too meta. The way I look at this effort is
investing a significant amount of time into figuring out how build jobs which
are simply too specific for every project could be described in a generic
manner appropriately in YAML. I can't help it but it sounds like we'd be
inventing a problem for ourselves to solve. It might very well be relevant in
the future, I think we need faster results now. Like I mentioned in my previous
replies, I totally share your view on Bash from the language POV, but if we
make sure these scripts will avoid using any kind of CLI parsing and wannabe
data structure implementation, then I believe we can have a reasonable
compromise for the time being. After all it all boils down to how many people
are willing to invest how much of their time into improving CI.

> 
> If we have the project build rules in ci/manifest.yml, we ahve
> lots of flexibility. We can easily trigger the builds in containers
> or VMs, or the local host, or whatever. 'lcitool' already has the
> command for runing builds in VMs, but that relies on build rules
> we defined separately in libvirt-ci.git and we've somewhat
> neglected the VM build logic since adopting containers.
> 
> Essentially ci/manifest.yml would become a fully self-contained
> canonical representation of any info needed to run builds, and be
> independant of gitlab CI, or any other CI framework we might like
> to plug into in the future. So 'lcitool' can be the entrypoint
> for triggering builds  that 100% match what gets run in gitlab
> 
> Yes, this only addresses the core build/unittest side of things.

^This on its own would not be a problem as long as we have other tools ready to
be chained in the pipeline (or locally) appropriately. Still, I'd be wary of
trying to make a swiss-army knife from lcitool by generating everything
especially with tools like Tekton which has become the industry standard for
pipeline and job generation on K8S, something that might become relevant to
libvirt in coming years too, so I'm not completely stoked about this idea
proposal as I'm afraid we'll be forced to ditch some of it in the future
nonetheless.

Regards,
Erik