"Varnau, Steve (Seaquest R&D)" <[email protected]> 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 _______________________________________________ OpenStack-Infra mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
