Re: [libvirt PATCH 0/5] ci: Use GitLab container registry
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
Attachments:
- signature.asc (application/pgp-signature — 833 bytes)