I am experiencing the exact same issue. Several reviews did not rebase
recently, which make some of my tests fail.
What should be the behaviour from the CI point of view ?
1) -1 and request a rebase
2) 0 and request a rebase
3) Ci to do the cherry pick but like Kevin was stating, it need some
Cherry-picking onto the target branch requires an extra step and custom
code that I wanted to avoid.
Right now I can just pass the gerrit ref into devstack's local.conf as the
branch and everything works.
If there was a way to get that Zuul ref, I could just use that instead and
no new code would
On 2014-07-21 11:36:43 -0700 (-0700), Kevin Benton wrote:
I see. So then back to my other question, is it possible to get
access to the same branch that is being passed to the OpenStack CI
devstack tests?
For example, in the console output I can see it uses a ref
like refs/zuul/
I see. So then back to my other question, is it possible to get access to
the same branch that is being passed to the OpenStack CI devstack tests?
For example, in the console output I can see it uses a ref
like refs/zuul/master/Z75ac747d605b4eb28d4add7fa5b99890.[1]
Is that visible somewhere
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,
On 2014-07-13 00:09:11 -0700 (-0700), Kevin Benton wrote:
[...]
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)?
In an independent pipeline, Zuul tests the change as merged to
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
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
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
Are these zuul refs publicly accessible so that the third party CI systems
could reference then to guarantee they are testing the same thing?
On Thu, Jul 3, 2014 at 11:31 AM, Jay Pipes jaypi...@gmail.com wrote:
On 07/03/2014 02:10 PM, Kevin Benton wrote:
The reason I thought it changed was
Hello,
What is the expected behavior of 3rd-party CI systems with regard to
checking out a patch. Should it be tested 'as-is' or should it be merged
into the proposed branch first and then tested?
As I understand it, this behavior for the main OpenStack CI check queue
changed to the latter some
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
It could be that it this behavior has merely become more noticeable
since Jenkins is now reverifying patch sets when new comments show up
and it sees that the patch set hasn't been verified recently.
Carl
On Tue, Jul 1, 2014 at 5:00 PM, Jeremy Stanley fu...@yuggoth.org wrote:
On 2014-07-01
13 matches
Mail list logo
