On 07/03/2014 04:37 PM, Kevin Benton wrote:
Are these zuul refs publicly accessible so that the third party CI
systems could reference then to guarantee they are testing the same thing?
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.
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:
https://review.openstack.org/#/c/93860/2
the git branch and HEAD you would check out to test the code as it is in
the code review would be:
git fetch https://review.openstack.org/openstack/nova
refs/changes/60/93860/2 && git checkout FETCH_HEAD
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.
You don't need to test whether that patch will merge into master, since
the upstream gate already does that.
Hope that helps,
-jay
On Thu, Jul 3, 2014 at 11:31 AM, Jay Pipes <[email protected]
<mailto:[email protected]>> wrote:
On 07/03/2014 02:10 PM, Kevin Benton wrote:
The reason I thought it changed was that this is the first cycle
where I
have encountered scenarios where my unit tests for the patch run
fine
locally, but then they fail when they are checked by Jenkins
(caused by
a change after the parent of my patch). I suppose I was just lucky
before and never had anything merge after I proposed a patch
that caused
a conflict with mine.
I suspect this is a problem then for many third-party CI systems
because
the simple approach of setting [PROJECT]_REPO and
[PROJECT]_BRANCH in
devstack to point to the gerrit server will not work correctly
since it
will just test the patch without merging it.
Where is this merging process handled in the OpenStack CI? Is
that done
in Zuul with the custom Zuul branch is passed to devstack?
Yes. The zuul-merger daemon is responsible for managing this, and
the devstack-gate project handles the checkout and setup of the git
repos for all of the OpenStack projects.
Best,
-jay
--
Kevin Benton
On Tue, Jul 1, 2014 at 4:00 PM, Jeremy Stanley
<[email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>> wrote:
On 2014-07-01 10:05:45 -0700 (-0700), Kevin Benton wrote:
[...]
> As I understand it, this behavior for the main OpenStack
CI check
> queue changed to the latter some time over the past few
months.
[...]
I'm not sure what you think changed, but we've (upstream
OpenStack
CI) been testing proposed patches merged to their target
branches
for years...
--
Jeremy Stanley
_________________________________________________
OpenStack-dev mailing list
[email protected].__org
<mailto:[email protected]>
<mailto:OpenStack-dev@lists.__openstack.org
<mailto:[email protected]>>
http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev
<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
--
Kevin Benton
_________________________________________________
OpenStack-dev mailing list
[email protected].__org
<mailto:[email protected]>
http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev
<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
_________________________________________________
OpenStack-dev mailing list
[email protected].__org
<mailto:[email protected]>
http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev
<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
--
Kevin Benton
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev