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

[Daniel P. Berrangé]

On Tue, Feb 07, 2023 at 10:56:59AM +0100, Erik Skultety wrote:
> 
> So, I had a brief look at https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2797tlab-runner exec this morning. Long story short,
> it's deprecated [1] and though it was scheduled for complete removal, that plan
> was put on hold for now. Nevertheless, it's not getting any features that are
> introduced to .gitlab-ci.yml. The gist is that it doesn't understand 'include'
> nor 'extends' which we're using heavily across our gitlab configuration
> hierarchy, so it's a no-go.

Urgh, I wasn't anticipating that they used completely different code to
interpret the config in the runner, than elsewhere in gitlab. No wonder
they want to kill it off :-(

>                            It also doesn't support artifacts in any form, so
> while it technically should be possible to save RPM builds in a volume (not
> sure if the bind mount is cleared on job completion or not) we could not pass
> them into a VM running the integration tests the same convenient way as we do
> in the CI.

Yep, I'm sure there are possible workarounds, but only worth it if the
rest of the thing is viable, which isn't the case with include/extends
support missing :-(

> In your reply you mentioned the unappealing complexity of the script
> potentially leading to bugs. At the same time though one currently can't consume
> .gitlab-ci.yml recipes to run a local integration test in a VM.

> So, how about I get rid of the multiplexing and CLI parsing by placing each job
> recipe in a standalone script or even going one step further and extract the
> commonalities to a separate file that would be source from within each job
> script? Would you consider that meeting each other halfway?

Lets consider the core CI (build + unit tests in .gitlab-ci.yml), separately
from the integration test CI (ci/integration-template.yml).

For the core CI, I'm just not convinced of the benefit of moving the commands
out into a shell script, as the set of commands is small and straightforward.

For the ingration CI though, I can see benefit because of all the command
logic related to fetching and building dependancies and setup tasks.

In retrospect this is a sign that we need to introduce a higher level frontend
for invoking the libvirt-tck tests. We already have avocado as a frontend to
replace the existing  'libvirt-tck' command line tool, but we never got rid of
the latter. We should probably get rid of the existing 'libvirt-tck' cli and
introduce a brand new pure python 'libvirt-tck' cli, with commands for running
avocado, optionally installing deps, and all the other interesting things devs
want help with.  The ci/integration-template.yml could then invoke this newly
re-invented 'libvirt-tck' command and eliminate most of the complexity in the
integration-template.yml file.

Essentially we need to look at the gitlab CI yml files as being a very thin
glue layer, and anything interesting should be in the end user facing tools
developers already use.

Introducing a new libvirt-tck python cli is likely not a quick fix though.
So if we split the ci/integration-template.yml commands out into a set of
bash scripts, that'll give us a good illustration of what commands we would
want in a new libvirt-tck cli impl. Then as the new libvirt-tck cli arrives,
we can eliminate the bash scripts from libvirt.git

I guess this would mean dropping much of this particular series, but keeping
much of the corresponding integration test series.

> As for POSIX compliance, I guess this would be a soft-requirement based on
> whether shellcheck was run during review, does gitlab do something better? IIUC
> there's no pre-check and you'll only know after a job was executed that there
> was an incompatible statement.

I think its ok if we use bash scripts as a short term solution, with a
plan to move to a more supportable python impl in future.


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