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
