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

[Andrea Bolognani]

On Mon, 2020-06-01 at 16:55 +0100, Daniel P. Berrangé wrote:
> By committing dockerfiles we have a simpler life
> 
>  - Fork libvirt.git
>  - Fork libvirt-ci.git
>  - Make code changes that need dockerfile update in libvirt.git
>  - Make lcitool related changes  in libvirt-ci.git
>  - Re-generate dockerfiles with lcitool from your fork
>  - If CI fails, repeat last two steps
>  - Commit lcitool related changes in libvirt-ci.git
>  - Submit merge request for libvirt.git
>  - Submit merge request for libvirt-ci.git
>  - Approve and merge libvirt.git merge request
>  - Approve and merge libvirt-ci.git merge request
> 
> In the second case, the preson updating libvirt-ci.git doesn't even
> have to be the same as the person who submits the libvirt.git updates,
> as it can be done out of band to some extent. eg we can do this:
> 
>  - Fork libvirt.git
>  - Make code changes that need dockerfile update in libvirt.git
>  - Edit dockerfiles with needed changes
>  - If CI fails, repeat last step
>  - Submit merge request for libvirt.git
>  - Approve and merge libvirt.git merge request
> 
> and
> 
>  - Fork libvirt-ci.git
>  - Make lcitool related changes  in libvirt-ci.git
>  - Commit lcitool related changes in libvirt-ci.git
>  - Submit merge request for libvirt-ci.git
>  - Approve and merge libvirt-ci.git merge request

These, and the ones made in the other message, are very solid points.

I have to say, however, that I'm not a fan of the idea of updating
the per-repository Dockerfiles before the corresponding code change
has made its way into libvirt-ci.git: ideally, it would works the
other way around and the libvirt.git commit would contain a reference
to the corresponding libvirt-ci.git commit, just like we're doing
right now in libvirt-dockerfiles.git.

-- 
Andrea Bolognani / Red Hat / Virtualization