Open Stack

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.