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
