On Wed, 2020-03-25 at 11:30 +0000, Daniel P. Berrangé wrote: > On Wed, Mar 25, 2020 at 12:18:00PM +0100, Andrea Bolognani wrote: > > On Wed, 2020-03-25 at 10:54 +0000, Daniel P. Berrangé wrote: > > > 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. > > The reason I think these should be different is that we're doing > different levels of testing on them. Native builds are full tests > (make distcheck), where as cross builds are build only (make all). > > Similarly the extra native builds are not repeating the full > distcheck as that's overkill (just make check). Okay, that's somewhat reasonable, though I'm still not entirely convinced this is something that we need to put quite as front and center as you have. Can you provide an implementation where the first batch of native and cross builds are executed in parallel, to demonstrate that goal can be achieved with code that's not too complicated or brittle? That's my main concern at this point. -- Andrea Bolognani / Red Hat / Virtualization
