On Wed, 2020-03-25 at 10:54 +0000, Daniel P. Berrangé wrote:
> On Wed, Mar 25, 2020 at 11:48:35AM +0100, Andrea Bolognani wrote:
> > 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.
I didn't know about that!
Anyway, even at the conceptual level splitting the jobs across smoke
tests and full coverage makes more sense to me than splitting them
across native builds, cross builds and... More native builds? That's
basically surfacing an implementation details at the UI level, so I'm
not too keen on that.
If you feel strongly about having the cross builds separated from the
native ones, maybe we can adopt an hybrid approach where we have
stages:
- artifacts
- smoke_native + smoke_cross # these run in parallel using the
- full_native + full_cross # trick you described above
but I'm not sure this is easy, or even possible, to implement.
--
Andrea Bolognani / Red Hat / Virtualization
