Open Stack

Ah, I see!  Thanks!

That's two of my stumper questions you've answered!  You're a star!

-Steve

From: XINYU ZHAO [mailto:xyzjerry at gmail.com]
Sent: Thursday, November 14, 2013 15:11
To: Varnau, Steve (Seaquest R&D)
Cc: openstack-infra at lists.openstack.org
Subject: Re: [OpenStack-Infra] Zuul parameters question

Hi Steve
>From what i observed, in scenarios where cross repo job is triggered, the ZUUL_REF is the same for both repo A and repo B.
This is an example:
http://logs.openstack.org/34/56334/1/gate/gate-tempest-devstack-vm-full/a0a2fa5/logs/devstack-gate-setup-workspace-new.txt.gz

refs/zuul/master/Z2dde909e70be42658ebde615fdb0f67e appears in repos of python-cinderclient, nova, and neutron. I guess the same zuul_ref is referencing the respective change in each repo.



On Thu, Nov 14, 2013 at 1:07 PM, Varnau, Steve (Seaquest R&D) <steve.varnau at hp.com<mailto:steve.varnau at hp.com>> wrote:
Hello OpenStack-Infra team,

Looking at the Zuul documentation and even the devstack-vm-gate-wrap.sh script, I'm not entirely clear on how Zuul passes information for multiple repos.

I understand that a triggering change only applies to one repo, since there are no cross-repo change transactions. But I know that for gate testing Zuul considers "shared change queues" if multiple repos run the same job.

Repos A and B are in the same change queue, change in A is being tested, and then a change in B enters the pipeline; in this case the Zuul parameters (ZUUL_REF) is for repo B (ZUUL_PROJECT).

How does the job get information about the preceding changes in repo A?  Documentation mentions ZUUL_CHANGE_IDS, but I don't know how that helps me.

Does Zuul wait and not run such cross-repo dependent jobs at the same time?

Thanks,
-Steve




_______________________________________________
OpenStack-Infra mailing list
OpenStack-Infra at lists.openstack.org<mailto:OpenStack-Infra at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-infra/attachments/20131114/ab332b9b/attachment-0001.html>