On Wed, Mar 25, 2020 at 11:27:31AM +0100, Andrea Bolognani wrote: > On Wed, 2020-03-25 at 09:35 +0100, Erik Skultety wrote: > > On Tue, Mar 24, 2020 at 06:21:24PM +0000, Daniel P. Berrangé wrote: > > > On Tue, Mar 24, 2020 at 06:47:01PM +0100, Andrea Bolognani wrote: > > > > * 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. > > > > Related to the availability of shared runners, for merge_requests/post_merge > > builds only, the PSI/OpenShift infra may actually help in order to achieve > > more stable execution times due to the usage of private runners. > > As explained by Dan, that will not help for the merge request builds, > because those are executed in the context of the submitter's fork and > as such don't have access to any runners we might deploy ourselves. > > It would help speed up the post merge phase, but once we move to a > merge request workflow we'll want to test as much as possible at the > time the merge request is submitted, and there won't be much that > needs to happen after the changes hit master... So dedicated runners > might actually not be useful outside of supporting non-Linux targets. NB, our current testing is all just build+unit testing. We want to expand to do integration testing, and that will also benefit from dedicated runners so that we can actually run stuff in a real OS, as opposed to a container where our functionality is much reduced. Also, even with merge request testing, we'll still want to test everything post-merge, as there is still a gap there. IIUC, the merge requests will test against the git master than that the merge request branch was based on. The fast-forward to current git master only happens after that. So there is a risk that merge request can pass testing but still result in breakage due to change to git master affecting the fast forward result. There might be ways to mitigate this by having a CI job itself try to do a fast-forwar to latest git master, rather than honouring the git state given to it, but I've not investigated. 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 :|
