[libvirt PATCH 0/5] ci: Use GitLab container registry

[Andrea Bolognani]

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