Re: [libvirt PATCH v2 6/9] gitlab: add x86_64 native CI jobs
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?
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;
* 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;
* 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.
Does that sound reasonable?
--
Andrea Bolognani / Red Hat / Virtualization