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