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
