On Mon, 2020-06-01 at 16:51 +0200, Pavel Hrdina wrote:
On Fri, May 29, 2020 at 03:00:39PM +0200, Andrea Bolognani wrote:
Branch: https://gitlab.com/abologna/libvirt/-/tree/ci-full-gitlab-registry Pipeline: https://gitlab.com/abologna/libvirt/pipelines/150891361
This is what we're already doing with the subprojects we've migrated to GitLab CI and, as of earlier today, all projects under the libosinfo umbrella.
Once this is merged, we can stop publishing container images on Quay and archive the libvirt-dockerfiles repository.
Patch 3/5 has been trimmed in order to comply with the size limits of the mailing list. You can grab the unabridged version with
$ git fetch https://gitlab.com/abologna/libvirt ci-full-gitlab-registry
This is a lot of files and lines of text/code. I was wondering about building the dockerfiles as part of the container_job_definition.
To me it seems like a lot of duplication and a lot of noise in the future if we decide to change the dockerfiles generation. The main difference that I can think of is that with files in repository we need to regenerate all the dockerfiles to apply changes made in libvirt-ci but with the automatic generation we would have that for free.
Both approaches have some benefits and drawbacks and I guess we could have some variable to prevent automatic generation of dockerfiles to make sure that unwanted changes in libvirt-ci doesn't affect CI for all libvirt repositories, on the other hand it would automatically check that changes to libvirt-ci doesn't break anything.
I personally don't like the need to introduce 5000+ lines just for compilation testing.
To prevent unwanted changes to slip in, we could make libvirt-ci a submodule and only bump the hash when we specifically want to update something. Overall I'd be perfectly okay with the approach you suggest, though I reserve the right to change my mind about this after having tried to implement it :) Adding Dan to the conversation so that he can weigh in. -- Andrea Bolognani / Red Hat / Virtualization