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

[Daniel P. Berrangé]

On Tue, Mar 24, 2020 at 06:47:01PM +0100, Andrea Bolognani wrote:
> On Tue, 2020-03-24 at 16:24 +0000, Daniel P. Berrangé wrote:
> > To control the total CI execution time, we split the native jobs into
> > two distinct stages. A representative set of distros are used as the
> > primary native build sanity test, run for everyone regardless of whether
> > pre/post merge, and on any branch. The remaining distros are set to run
> > after the cross builds, and only execute for master branch, and thus
> > will only run for post-merge. When we switch to using a merge request
> > workflow, these extra jobs can be triggered when the merge request is
> > opened.
> 
> I don't get the rationale behind the split.
> 
> Right now we're not using merge requests, but we're limiting the
> number of jobs for the merge request case; at the same time, we say
> that once we switch to a MR-based workflow, we're going to run the
> extra jobs on each merge request as well. So what does the
> distinction buy us?

With this split today, if I push to my private fork, then the
reduced set of jobs run. This gives quick turnaround for developers
developing patches.

When it gets reviewed & pushed to master, the full set run post
merge.

In the future, when we switch to merge requests, we'll change
it so that the full set run when the merge request is opened,
instad of post-merge.

What is run for developers private branches will remain the
same

> I think a better split would be:
> 
>   * pick a selection of jobs that includes both native and cross
>     build, across various distros of different vintage, such that
>     they can all run without waiting on shared runners. This can be
>     used by developers as a reasonably quick (~20 minutes) smoke
>     test while working on a feature;

"without waiting on shared runners" is undefined, as whether you
wait & how long, is dependant on many things outside our control.
As notedin the cover letter though, this minimal set of native
+ cross build jobs gives about a 35 min turn around based on
load I see today. I think that's acceptably fast.

>   * run every other build as a second stage in the pipeline, both
>     for master and (later) for merge requests, to validate patches
>     as thoroughly as possible before they get into libvirt;

There's no point in doing both master & merge requests - only one
or the other. Right now since we're not doing merge reuqests, I
picked master. Later we'll switch it to be on merge requests.

>   * run the website and potfile jobs for master only, as their
>     purpose is not to validate the build (the regular Fedora 31 job
>     will have done that already) but to publish the artifacts.

Doing the website job on all branches was intentionale because by
publishing the artifact, developers can now browse the website
for their job during development to see the effect on their changes.
eg for my most recent job I can view:

https://berrange.gitlab.io/-/libvirt/-/jobs/483635204/artifacts/website/index.html

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