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

[Erik Skultety]

On Wed, Feb 15, 2023 at 09:06:46AM +0100, Erik Skultety wrote:
> 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.

Ping. I'd still like some conclusion on this whether the proposed approach
(with changes like decomposition to scripts) is a complete no go and I need to
drop the whole series or if there's anything we can do about it right now.

Regards,
Erik