Open Stack

On Wed, Dec 5, 2018, at 9:18 AM, Eric Fried wrote:
> This started off as a response to some questions Sundar asked, but I
> thought it might be interesting/useful for new[er] OpenStack developers
> at large, so broadcasting.

Snip. Note the content I've removed was really good and worth a read if you work with stacks of commits and Gerrit.

> > * If you have a patch sequence A followed by B, where patch B depends
> on patch A,
> >   how do you communicate that in the submission?
> 
> If they're in the same commit series, like the example above, It Just
> Happens. Zuul and the CIs know to pull the whole series when they run;
> gerrit won't merge N+1 until N is merged; etc.
> 
> If they're *not* in the same commit series, or if they're not in the
> same repository, you can use Depends-On in the commit message, to the
> same effect.  (But I'm not sure if/how Depends-On works for feature
> branches.)

This does work with feature branches as long as the assumption that a feature branch is roughly equivalent to master holds (typically this is the case as new features go into master).

On the Zuul side of things Zuul ensures that every branch for each project under test (as specified by depends on and required-projects in the job config) is up to date. This includes applying any speculative state from gating or dependencies. It is then up to tools like devstack (and in the past devstack-gate) to consume those branches as necessary. For example grenade will start with stable/old and upgrade to stable/new|master. Typically in the case of feature branches the assumption in the tooling is use the feature branch in all the projects and if they don't have that feature branch fall back to master. This is where the feature branch implies something like master assumption comes from.

You can always refer back to the logs to see what exactly was installed for each project under test to confirm it was testing what you expected it to.

Clark