[openstack-dev] Cross-Repo Dependencies in Zuul

Sean Dague sean at dague.net
Tue Feb 10 23:09:52 UTC 2015


On 02/10/2015 05:47 PM, Ihar Hrachyshka wrote:
> So cool! A comment inline.
> 
> On 02/10/2015 11:26 PM, James E. Blair wrote:
>> Hi,
> 
>> We have added support for cross-repo dependencies (CRD) in Zuul.
>> The important bits:
> 
>> * To use them, include "Depends-On: <gerrit-change-id>" in the
>> footer of your commit message.  Use the full Change-ID ('I' + 40
>> characters).
> 
>> * These are one-way dependencies only -- do not create a cycle.
> 
>> * This is what all the grey dots and lines are in the check
>> pipeline.
> 
>> Cross-Repo Dependencies Explained 
>> =================================
> 
>> There are two behaviors that might go by the name "cross-repo 
>> dependencies".  We call them one-way and multi-way.
> 
>> Multi-way CRD allow for bidirectional links between changes.  For 
>> instance, A depends on B and B depends on A.  The theory there is
>> that both would be tested together and merged as a unit.  This is
>> _not_ what we have implemented in Zuul.  Discussions over the past
>> two years have revealed that this type of behavior could cause
>> problems for continuous deploments as it means that two components
>> must be upgraded simultaneously.  Not supporting this behavior is a
>> choice we have made.
> 
> Though I understand your reasoning behind not providing atomic merges
> of multiple commits, I want to say that the feature would be very
> useful for projects that are not decoupled enough. F.e. see neutron
> advanced services repos that are split out of main neutron project but
> still use lots of code from neutron namespace, making it hard to
> introduce changes into the main repo without breaking advanced
> services for some time. The same is true for decomposed plugins and
> mechanism drivers for neutron.

Atomic merges across git trees is a really bad idea.

If you want atomic merges, there is an easy solution, be one git tree.

If you are allowing folks externally to consume your code directly via
import, then that needs to be a stable interface that has deprecation
rules associated with it. All else is craziness.

	-Sean

-- 
Sean Dague
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 465 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150210/6f6cff4d/attachment.pgp>


More information about the OpenStack-dev mailing list