On Tue, Mar 24, 2020 at 06:21:24PM +0000, Daniel P. Berrangé wrote:
> 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.

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.

Erik

Reply via email to