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

Pavel Hrdina phrdina at redhat.com
Mon Jun 1 14:51:19 UTC 2020

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

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20200601/7e60125a/attachment-0001.sig>

More information about the libvir-list mailing list