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]>> 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]
<mailto:[email protected]>
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
