Excerpts from Karpenko, Oleksandr (Nokia - DE/Ulm)'s message of 2017-01-23 13:24:08 +0000: > Hallo together, > > Sorry for bothering you but I am not able to find any zuul specific mailing > list. > First of all if there is some better place to ask questions, please let me > know and I will do it there. > > We are considering to use Zuul in a project split across many git > repositories and we are in a proof of concept phase now. I have submitted for > the review first problems we have found > (https://review.openstack.org/#/c/423337/ , > https://review.openstack.org/#/c/424055/). > > Gerrit has a nice feature called 'Submit whole topic'. You can have reviews > in several repositories within the same topic and gerrit allows to submit > them together very close in time. When the first change is ready for Submit, > 'Submit' button stays gray until all other reviews in the same topic are > ready and then by pressing the button in any of those changes all of them are > submitted. > > We have gate pipeline (DependentPipeline) in Zuul for Cross Project Testing > which is triggered on code-review: 2 and on success does gerrit submit. The > gate pipeline runs when the first change gets code-review: 2 and if all > other changes have also code-review: 2, zuul submits all of them without > testing the rest. > > Does Zuul have any support for 'Submit whole topic' gerrit feature? I am not > able to find any. > > Does DependentPipeline have support for gerrit topic concept? It sounds at > least reasonable to wait until all changes in the same topic get reviewed and > then start DependentPipeline once (instead of 3 times in case of 2 > repositories). > > Does our concept make sense at all or there are other ways to do it? We would > like to reduce an effect of 'diamond dependency problem' by submitting > related to each other changes close in time. For example when A depends on B > and C. B and C depends on D. We would like to test A with related to each > other changes in B and C (e.g. D integration) and submit changes in B and C > very close in time. Because when B integrates D is much faster as C, A cannot > be built until C is ready with D integration. This is not exactly what > 'Depends-On:' is doing because changes in B and C does not depend on each > other. >
The intention of DependentPipeline is to make sure every commit, of every repository, works together with the commits that it claims to depend on. So what you have is this graph: A---->B-->D \ -->C-->D If you approve A first, and D last, I believe the Dependent Pipeline Manager will try to test them like this: D D+B+C D+B+C+A But that's only if you approve A first, and D last. Developers would definitely be able to approve D, then B, and D would go in before C. There's no good way to resolve this with DependentPipelineManager. Because ideally you could make B and C depend on each other. But DependentPipelineManager will fail because that creates a cycle. Perhaps this a use case for making a pipeline manager that allows for cycles. For now, you're best off unrolling in your code. That means that you likely need a "Z" that depends on A, B, and C and turns on whatever behavior you wanted with all of them in place. _______________________________________________ OpenStack-Infra mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
