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

[Daniel P. Berrangé]

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:
> > > On Wed, 2020-03-25 at 09:35 +0100, Erik Skultety wrote:
> > > > Related to the availability of shared runners, for merge_requests/post_merge
> > > > builds only, the PSI/OpenShift infra may actually help in order to achieve
> > > > more stable execution times due to the usage of private runners.
> > > 
> > > As explained by Dan, that will not help for the merge request builds,
> > > because those are executed in the context of the submitter's fork and
> > > as such don't have access to any runners we might deploy ourselves.
> > > 
> > > It would help speed up the post merge phase, but once we move to a
> > > merge request workflow we'll want to test as much as possible at the
> > > time the merge request is submitted, and there won't be much that
> > > needs to happen after the changes hit master... So dedicated runners
> > > might actually not be useful outside of supporting non-Linux targets.
> > 
> > NB, our current testing is all just build+unit testing. We want to expand
> > to do integration testing, and that will also benefit from dedicated runners
> > so that we can actually run stuff in a real OS, as opposed to a container
> > where our functionality is much reduced.
> 
> Good point, I was just thinking in terms of migrating what we already
> have to GitLab rather than building upon it.
> 
> This kind of testing will still be limited by the fact that merge
> requests will not be able to use these dedicated runners. Compare
> this to something like KubeVirt's CI, where proper integrations tests
> are executed for each and every merge request...

BTW, when comparing to CI done in GitHub be aware that you're comparing
apples & oranges. Traditionally most/all GitHub CI setups were done via
external services / bots, feeding results back with the GitHub API. This
approach is possible with the GitLab API too if you want to ignore the
built-in CI facilities.

IOW, it would be entirely possible to ignore the GitLab runners / CI
system, and have a integration test harness that just watched for new
Merge requests, runs tests on them, and then adds a comment and/or
approval mark to the merge request.

My preference is to do as much as possible using the GitLab CI setup though,
since that's the more commonly expected approach. If we hit roadblocks that
are important, we can take the external service/bot approach where needed.

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 :|