On Thu, Oct 11, 2018, at 7:17 AM, Ben Nemec wrote: > > > On 10/11/18 8:53 AM, Felix Enrique Llorente Pastora wrote: > > So for example, I don't see why changes at tripleo-quickstart can be > > reset if tripleo-ui fails, this is the kind of thing that maybe can be > > optimize. > > Because if two incompatible changes are proposed to tripleo-quickstart > and tripleo-ui and both end up in parallel gate queues at the same time, > it's possible both queues could get wedged. Quickstart and the UI are > not completely independent projects. Quickstart has roles for deploying > the UI, which means there is a connection there. > > I think the only way you could have independent gate queues is if you > had two disjoint sets of projects that could be gated without any use of > projects from the other set. I don't think it's possible to divide > TripleO in that way, but if I'm wrong then maybe you could do multiple > queues.
To follow up on this the Gate pipeline queue that your projects belong to are how you indicate to Zuul that there is coupling between these projects. Having things set up in this way allows you to ensure (through the Gate and Zuul's speculative future states) that a change to one project in the queue can't break another because they are tested together. If your concern is "time to merge" splitting queues won't help all that much unless you put all of the unreliable broken code with broken tests in one queue and have the reliable code in another queue. Zuul tests everything in parallel within a queue. This means that if your code base and its tests are reliable you can merge 20 changes all at once and the time to merge for all 20 changes is the same as a single change. Problems arise when tests fail and these future states have to be updated and retested. This will affect one or many queues. The fix here is to work on making reliable test jobs so that you can merge all 20 changes in the span of time it takes to merge a single change. This isn't necessarily easy, but helps you merge more code and be confident it works too. Clark __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
