Hi Sean, Thanks for you quick and detailed answer. It's good to know that such situations are solved with "sibling specs". Also the "Depends-On:" hint was very informative for me, especially that this statement can be evaluated by the CI/CD chain to prevent it from breaking. Cheers, Manuel On 7/11/22 13:13, Sean Mooney wrote:

On Mon, 2022-07-11 at 12:18 +0200, Manuel Bentele wrote:

...

Hi all,

I have two general developer questions:

* Where are the blueprints and specs located that address changes across the code base? in generall we create "sibling specs" in each project when we have cross project work. its rare that we have more then 2 or 3 projects that take part in any one feature or change so we dont have a singel repo for specs across all repos.

the close thing we have to that is a a TC selected cross porject goal. but even then while the goal document might be held locally we would still track any work on that goal within each proejct.

...

* How to deal with changes that have dependencies on multiple repositories (where a specific merge and release order needs to be satisfied)?

zuul (or ci/gating system) support cross repo dependiceis and speculitive merging for testing via "Depends-On:" lines in the commit message.

That will prevent a patch on project A form merging until the patch it depens on in project B is merged however for testing if you are using the devstack jobs it will locally merge the patch to proejct B when testing the patch to project A.

this is generaly refered to as co-gatating.

To enable this the jobs have to declare the other project as a required-project which will resutl in zuul prepareing a version fo the git repo with all depencies merged which the jobs can then use instead of the current top of the master branch when testing.

the simple tox based unit tests do not support using deps form git. they install from pypi so unit/functional tests will not pass until a change in a lib is merged but the integration jobs such as the devstack ones will work.

...

For example: An enumeration member has to be added and merged in repository A before it can be used in repository B and C. If this order is not satisfied, a DevStack setup may break. yes which is a good thing. we want devstack to brake in this case since the set of code you are deploying is broken. but for a ci perspecitve depend-on

in general however, out side of constantats and data structure taht are part of the lib api if project A depens on project B, the Project A should mock all calls to B in its unit tests and provide a testfixture for B in its functional tests where that is resonable if they want to mitigate the dependicty issues. prevents this form happening.

for local developemnt you can override the branches used and can tell devstack to deploy specific patch reviiosn form gerrit or spicic git sha's/branches via usign the <project>_repo and <project>_branch vars that you can define in the local.conf. look at the stackrc file for examples.

...

Regards, Manuel