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