Clint Byrum <[email protected]> writes: > Excerpts from Oleksandr Karpenko's message of 2017-01-27 16:46:24 +0100: >> Hello together, >> >> Thanks for your answers. >> >> Yes, we are interested in this feature and ready to contribute. But we >> will need a support from your side for clear understanding how to >> implement it. >> >> My vision is a following: >> >> Define a new configuration parameter for 'manager: >> DependentPipelineManager', e.g. 'manager-policy: aggregate-gerrit-topics'. >> >> When change set arrives DependentPipelineManager and topic is not empty, >> consult gerrit server whether other change sets effecting pipeline >> exists. And if it is a case, delay a pipeline until all change sets with >> the same topic are ready to be proceeded. >> > > That could work, for sure. However, with Zuul growing the ability to > push to Gerrit directly soon, it's unnecessarily Gerrit-dependent. We can > simply make Zuul do this with its own dependency specification methods. > That way topics and coordinated landings can stay de-coupled from > one-another.
Agreed. That should not be too difficult and should work with any Zuul driver, not just Gerrit. The most difficult part of this work will be altering the pipeline managers and data model to represent co-dependent changes so that each co-dependent change is tested with all of the others. Currently the queue is a DAG with exactly one item "ahead" of another in the queue (but possibly multiple items behind), and each item corresponding to a change. The data model would need to be altered to account for changes being 'siblings' in some way. Perhaps that means that an item should contain multiple changes (this sounds elegant). Or non-live items representing each of the changes should be enqueued ahead of real items representing the changes (this is probably easier but sounds very awkward). Or perhaps the queue should no longer be a DAG and should allow cycles (this sounds difficult). -Jim _______________________________________________ OpenStack-Infra mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
