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