<div dir="ltr">3rd party systems do need to test the patch rebased against master since that's what OpenStack is testing. Otherwise, there are conditions where the patch can fail in its current position but not rebased against master so it will look like something is wrong with the 3rd party system. Similarly, the patch might pass without being rebased and then fail once merged into master and cause all subsequent patches to fail for the 3rd party system. <div>

<br></div><div><div>><span style="font-family:arial,sans-serif;font-size:13px">Well, if you aren't using Zuul to handle the merging of dependent patchsets, I'm not entirely sure the ZUUL_ environment variables are going to help much.</span></div>

<div><br></div><div><font face="arial, sans-serif">Can you elaborate on this some more? Does Zuul only cherry-pick the top commit of the proposed patch instead of merging the proposed patch's branch into master (which would merge all dependent patchsets)?</font></div>

</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jul 6, 2014 at 5:53 PM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On 07/03/2014 04:37 PM, Kevin Benton wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Are these zuul refs publicly accessible so that the third party CI<br>
systems could reference then to guarantee they are testing the same thing?<br>
</blockquote>
<br></div>
Well, if you aren't using Zuul to handle the merging of dependent patchsets, I'm not entirely sure the ZUUL_ environment variables are going to help much.<br>
<br>
That said, if all you want is to test the specific branch/patch that is proposed in a Gerrit code review, then you just need to check out the commit that is referenced on the code review. For instance, if you go to this review and patchset:<br>


<br>
<a href="https://review.openstack.org/#/c/93860/2" target="_blank">https://review.openstack.org/#<u></u>/c/93860/2</a><br>
<br>
the git branch and HEAD you would check out to test the code as it is in the code review would be:<br>
<br>
git fetch <a href="https://review.openstack.org/openstack/nova" target="_blank">https://review.openstack.org/<u></u>openstack/nova</a> refs/changes/60/93860/2 && git checkout FETCH_HEAD<br>
<br>
What Zuul does is provide support for managing *dependent patch queues*, allowing jobs to be aborted if a dependent patch has failed to merge or successfully run its test jobs.<br>
<br>
You don't need to test whether that patch will merge into master, since the upstream gate already does that.<br>
<br>
Hope that helps,<br>
-jay<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
On Thu, Jul 3, 2014 at 11:31 AM, Jay Pipes <<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a><br></div><div><div class="h5">
<mailto:<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>>> wrote:<br>
<br>
    On 07/03/2014 02:10 PM, Kevin Benton wrote:<br>
<br>
        The reason I thought it changed was that this is the first cycle<br>
        where I<br>
        have encountered scenarios where my unit tests for the patch run<br>
        fine<br>
        locally, but then they fail when they are checked by Jenkins<br>
        (caused by<br>
        a change after the parent of my patch). I suppose I was just lucky<br>
        before and never had anything merge after I proposed a patch<br>
        that caused<br>
        a conflict with mine.<br>
<br>
        I suspect this is a problem then for many third-party CI systems<br>
        because<br>
        the simple approach of setting [PROJECT]_REPO and<br>
        [PROJECT]_BRANCH in<br>
        devstack to point to the gerrit server will not work correctly<br>
        since it<br>
        will just test the patch without merging it.<br>
<br>
        Where is this merging process handled in the OpenStack CI? Is<br>
        that done<br>
        in Zuul with the custom Zuul branch is passed to devstack?<br>
<br>
<br>
    Yes. The zuul-merger daemon is responsible for managing this, and<br>
    the devstack-gate project handles the checkout and setup of the git<br>
    repos for all of the OpenStack projects.<br>
<br>
    Best,<br>
    -jay<br>
<br>
        --<br>
        Kevin Benton<br>
<br>
<br>
        On Tue, Jul 1, 2014 at 4:00 PM, Jeremy Stanley<br>
        <<a href="mailto:fungi@yuggoth.org" target="_blank">fungi@yuggoth.org</a> <mailto:<a href="mailto:fungi@yuggoth.org" target="_blank">fungi@yuggoth.org</a>><br></div></div><div class="">
        <mailto:<a href="mailto:fungi@yuggoth.org" target="_blank">fungi@yuggoth.org</a> <mailto:<a href="mailto:fungi@yuggoth.org" target="_blank">fungi@yuggoth.org</a>>>> wrote:<br>
<br>
             On 2014-07-01 10:05:45 -0700 (-0700), Kevin Benton wrote:<br>
             [...]<br>
              > As I understand it, this behavior for the main OpenStack<br>
        CI check<br>
              > queue changed to the latter some time over the past few<br>
        months.<br>
             [...]<br>
<br>
             I'm not sure what you think changed, but we've (upstream<br>
        OpenStack<br>
             CI) been testing proposed patches merged to their target<br>
        branches<br>
             for years...<br>
             --<br>
             Jeremy Stanley<br>
<br></div>
             ______________________________<u></u>___________________<br>
             OpenStack-dev mailing list<br>
        OpenStack-dev@lists.openstack.<u></u>__org<br>
        <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.<u></u>openstack.org</a>><br>
             <mailto:<a href="mailto:OpenStack-dev@lists." target="_blank">OpenStack-dev@lists.</a>__<a href="http://openstack.org" target="_blank"><u></u>openstack.org</a><br>
        <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.<u></u>openstack.org</a>>><br>
<br>
        <a href="http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev" target="_blank">http://lists.openstack.org/__<u></u>cgi-bin/mailman/listinfo/__<u></u>openstack-dev</a><div class=""><br>
        <<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a>><br>
<br>
<br>
<br>
<br>
        --<br>
        Kevin Benton<br>
<br>
<br></div>
        ______________________________<u></u>___________________<br>
        OpenStack-dev mailing list<br>
        OpenStack-dev@lists.openstack.<u></u>__org<br>
        <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.<u></u>openstack.org</a>><br>
        <a href="http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev" target="_blank">http://lists.openstack.org/__<u></u>cgi-bin/mailman/listinfo/__<u></u>openstack-dev</a><br>
        <<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a>><br>
<br>
<br>
    ______________________________<u></u>___________________<br>
    OpenStack-dev mailing list<br>
    OpenStack-dev@lists.openstack.<u></u>__org<br>
    <mailto:<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.<u></u>openstack.org</a>><br>
    <a href="http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev" target="_blank">http://lists.openstack.org/__<u></u>cgi-bin/mailman/listinfo/__<u></u>openstack-dev</a> <<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a>><div class="">

<br>
<br>
<br>
<br>
<br>
--<br>
Kevin Benton<br>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
<br>
</div></blockquote><div class="HOEnZb"><div class="h5">
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Kevin Benton</div>
</div>