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. Pavel
Attachment:
signature.asc
Description: PGP signature
