Open Stack

"Varnau, Steve (Seaquest R&D)" <steve.varnau at hp.com> writes:

> Antoine,
>
> Yes, I ran into same confusion recently. For dependent pipeline, Zuul will provide the same ZUUL_REF for each repo that has pipeline changes to test. So in test of second change, if you check out the $ZUUL_REF version for both repos, you'll indeed get the change set you want:
>
>>  repoA with change 1
>>  repoB with change 2

Yep.  And I just made some changes to devstack-gate that I hope make the
process a little clearer.  Here's where the interesting bit is:

  http://git.openstack.org/cgit/openstack-infra/devstack-gate/tree/functions.sh#n141

Basically it tries to check out the Zuul ref for the branch you ask it
to (usually that should be $ZUUL_BRANCH, but occasionally we set it to
"stable/foo" to test some cross-branch situations (like a change to
master doesn't break the upgrade script from stable to master)).  For
the simple case, it should just be $ZUUL_BRANCH.

So if the branch exists, it tries to check out the zuul ref for the
branch, and if not, the zuul ref for master.  If there are no zuul refs
for the project, then it tries to check out the tip of the branch if it
exists, and if the branch doesn't exist, the tip of master.

If you scan down the list of projects in a dependent queue, each
project-branch combination gets a zuul ref created for it the first time
that project-branch shows up in the queue with a change.  For each
subsequent change, there will be a zuul ref for that project-branch as
well.  This way you can always check out the future state of the whole
system for each change in the queue.  For example, with these three
changes in the queue:

  repoA branch master change 1 zuul_ref master/Z1
  repoB branch stable change 2 zuul_ref stable/Z2
  repoB branch master change 3 zuul_ref master/Z3

The following zuul refs will exist:

repoA/master/Z1: repoA branch master with change 1 applied

repoA/master/Z2: repoA branch master with change 1 applied
repoB/stable/Z2: repoB branch stable with change 2 applied

repoA/master/Z3: repoA branch master with change 1 applied
repoB/stable/Z3: repoB branch stable with change 2 applied
repoB/master/Z3: repoB branch master with change 3 applied

So you can see the algorithm to check out what's needed in order to test
change 3 is to checkout the Z3 ref on each of the project-branch
combinations you are interested in.  That's probably just the master
branch (unless you're doing cross-branch testing like we sometimes do),
so you'll probably check out repoA/master/Z3 and repoB/master/Z3, and
end up with change 1 applied to repoA and change3 applied to repoB (and
you won't see change 2 because you're not interested in that branch).
If Z3 doesn't exist for that project-branch, just checkout master.  So
if there were a repoC, there would be no zuul ref for repoC/master/Z3,
so you should checkout master.

If you want to see more of these examples, some of them complicated, I
just added "unit tests" to devstack gate:

  http://git.openstack.org/cgit/openstack-infra/devstack-gate/tree/test-functions.sh

-Jim