Re: [libvirt PATCH 0/5] ci: Use GitLab container registry
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