<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Sean,</p>
<p>Thanks for you quick and detailed answer. <span class="VIiyi"
lang="en"><span class="JLqJ4b ChMk0b"
data-language-for-alternatives="en"
data-language-to-translate-into="de" data-phrase-index="0"
data-number-of-phrases="3"><span class="Q4iAWc">It's good to
know that such situations are solved with "sibling specs". </span></span></span>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.</p>
<p>Cheers,<br>
Manuel<br>
<br>
</p>
<div class="moz-cite-prefix">On 7/11/22 13:13, Sean Mooney wrote:<br>
</div>
<blockquote type="cite"
cite="mid:52879fafe8d91f9699439a12ded0affbb7cb2feb.camel@redhat.com">
<pre class="moz-quote-pre" wrap="">On Mon, 2022-07-11 at 12:18 +0200, Manuel Bentele wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Hi all,
I have two general developer questions:
* Where are the blueprints and specs located that address changes
across the code base?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap=""> * How to deal with changes that have dependencies on multiple
repositories (where a specific merge and release order needs to be
satisfied)?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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.
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.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">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
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.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Regards,
Manuel
</pre>
</blockquote>
</blockquote>
</body>
</html>