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

[Daniel P. Berrangé]

On Wed, Mar 25, 2020 at 11:48:35AM +0100, Andrea Bolognani wrote:
> On Tue, 2020-03-24 at 18:21 +0000, Daniel P. Berrangé wrote:
> > On Tue, Mar 24, 2020 at 06:47:01PM +0100, Andrea Bolognani wrote:
> > > 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
> 
> Okay, I understand the rationale now, and I can see that we were
> arguing for very similar approaches the entire time - it's just that
> I could not see that. Thanks for taking the time to spell it out for
> me :)
> 
> > >   * 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.
> 
> Given the intentions, I think the current split can be improved
> further: having cross_build as a separate stage from native_build
> means that the former has to wait before the latter is done to even
> start, and that makes wait times longer.

By default jobs in a stage get given a dependency

  "needs: [.... jobs from prev stage...]"

which serializes each stage, but that is not mandatory. We can
set the stages to allow parallel execution across stages using
an explicit 'needs: []'.  So we can keep stage as a conceptual
grouping without affecting parallelism.


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