[libvirt PATCH v2 6/9] gitlab: add x86_64 native CI jobs

Daniel P. Berrangé berrange at redhat.com
Wed Mar 25 11:43:08 UTC 2020


On Wed, Mar 25, 2020 at 12:27:33PM +0100, Andrea Bolognani wrote:
> On Wed, 2020-03-25 at 10:44 +0000, Daniel P. Berrangé wrote:
> > On Wed, Mar 25, 2020 at 11:27:31AM +0100, Andrea Bolognani wrote:
> > Also, even with merge request testing, we'll still want to test everything
> > post-merge, as there is still a gap there.  IIUC, the merge requests will
> > test against the git master than that the merge request branch was based
> > on. The fast-forward to current git master only happens after that.
> > 
> > So there is a risk that merge request can pass testing but still result
> > in breakage due to change to git master affecting the fast forward result.
> > 
> > There might be ways to mitigate this by having a CI job itself try to do
> > a fast-forwar to latest git master, rather than honouring the git state
> > given to it, but I've not investigated.
> 
> There has to be a way to tell GitLab to re-test the actual code that
> is about to hit master when a merge request is approved... It would
> be kind of insane otherwise, since both the base branch and the set
> of CI tests themselves might be weeks, if not months old by the time
> a merge request is approved.

It isn't as big a deal as you think, because the older something is,
the less likely a fast-forward merge is going to suceed without hitting
conflicts. When there are conflicts, you're forced to rebase the merge,
which will trigger tests again. So this is only a problem on simple
patches which are fast forwardable but then semantically incorrect.
And of course the reviewer will often notice incompatibilities themselves.

GitLab does do the correct thing in testing the post-merge result for
a merge request when using a branch from the same repo - just doens't
do it for forked repos. This is related to the previous issue I mentioned
with forks / runners.

There's a variety of issues talking about it - the key phrases to look
for are "merge train" which is GitLab terminology for this feature.

https://gitlab.com/gitlab-org/gitlab/-/issues/9713
https://gitlab.com/gitlab-org/gitlab/-/issues/11935
https://gitlab.com/gitlab-org/gitlab/-/issues/11934

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|




More information about the libvir-list mailing list