[neutron][ci] Gate failure
Hi,
It looks that we (again) have some broken gate. This time it’s problem with neutron-tempest-plugin-designate-scenario job which is failing 100% times. See [1] for details. Patch [2] is proposed so now lets wait until it will be merged and You can than rebase Your neutron patches to make Zuul happy again :)
[1] https://bugs.launchpad.net/devstack/+bug/1834849 [2] https://review.opendev.org/#/c/668447/
— Slawek Kaplonski Senior software engineer Red Hat
On 2019-07-01 14:44:29 +0200 (+0200), Slawek Kaplonski wrote: [...]
Patch [2] is proposed so now lets wait until it will be merged and You can than rebase Your neutron patches to make Zuul happy again
[...]
There should be no need to rebase changes for Zuul to make use of a fix which merges to the branch. Just a "recheck" comment is all you need. Zuul always merges your change onto the latest branch state when starting new builds, so the *only* reason to rebase should be if you have a legitimate merge conflict preventing it from being tested at all. This is not new, this is the way Zuul has always worked.
Hi,
On 1 Jul 2019, at 15:08, Jeremy Stanley fungi@yuggoth.org wrote:
On 2019-07-01 14:44:29 +0200 (+0200), Slawek Kaplonski wrote: [...]
Patch [2] is proposed so now lets wait until it will be merged and You can than rebase Your neutron patches to make Zuul happy again
[...]
There should be no need to rebase changes for Zuul to make use of a fix which merges to the branch. Just a "recheck" comment is all you need. Zuul always merges your change onto the latest branch state when starting new builds, so the *only* reason to rebase should be if you have a legitimate merge conflict preventing it from being tested at all. This is not new, this is the way Zuul has always worked.
So if I have fix for some issue in Neutron repo (lets say patch A), and other patch to neutron repo (patch B) which is failing because of this issue, I don’t need to rebase my failing patch B to include fix from patch A and to get +1 from Zuul? Am I understanding correct what You wrote? I know that it is like that in gate queue but I though that in check queue it works differently.
-- Jeremy Stanley
— Slawek Kaplonski Senior software engineer Red Hat
On Mon, Jul 1, 2019, at 7:55 AM, Slawek Kaplonski wrote:
Hi,
On 1 Jul 2019, at 15:08, Jeremy Stanley fungi@yuggoth.org wrote:
On 2019-07-01 14:44:29 +0200 (+0200), Slawek Kaplonski wrote: [...]
Patch [2] is proposed so now lets wait until it will be merged and You can than rebase Your neutron patches to make Zuul happy again
[...]
There should be no need to rebase changes for Zuul to make use of a fix which merges to the branch. Just a "recheck" comment is all you need. Zuul always merges your change onto the latest branch state when starting new builds, so the *only* reason to rebase should be if you have a legitimate merge conflict preventing it from being tested at all. This is not new, this is the way Zuul has always worked.
So if I have fix for some issue in Neutron repo (lets say patch A), and other patch to neutron repo (patch B) which is failing because of this issue, I don’t need to rebase my failing patch B to include fix from patch A and to get +1 from Zuul? Am I understanding correct what You wrote? I know that it is like that in gate queue but I though that in check queue it works differently.
You don't need to rebase or use depends on once change A has merged because Zuul will always merge your proposed changes (change B) to the target branch (which includes change A).
If you want things to go green prior to change A merging you will need to rebase or use depends on.
Clark
Hi,
On 1 Jul 2019, at 17:03, Clark Boylan cboylan@sapwetik.org wrote:
On Mon, Jul 1, 2019, at 7:55 AM, Slawek Kaplonski wrote:
Hi,
On 1 Jul 2019, at 15:08, Jeremy Stanley fungi@yuggoth.org wrote:
On 2019-07-01 14:44:29 +0200 (+0200), Slawek Kaplonski wrote: [...]
Patch [2] is proposed so now lets wait until it will be merged and You can than rebase Your neutron patches to make Zuul happy again
[...]
There should be no need to rebase changes for Zuul to make use of a fix which merges to the branch. Just a "recheck" comment is all you need. Zuul always merges your change onto the latest branch state when starting new builds, so the *only* reason to rebase should be if you have a legitimate merge conflict preventing it from being tested at all. This is not new, this is the way Zuul has always worked.
So if I have fix for some issue in Neutron repo (lets say patch A), and other patch to neutron repo (patch B) which is failing because of this issue, I don’t need to rebase my failing patch B to include fix from patch A and to get +1 from Zuul? Am I understanding correct what You wrote? I know that it is like that in gate queue but I though that in check queue it works differently.
You don't need to rebase or use depends on once change A has merged because Zuul will always merge your proposed changes (change B) to the target branch (which includes change A).
Thx a lot for explanation. I didn’t know that it is like that in check queue :)
If you want things to go green prior to change A merging you will need to rebase or use depends on.
Clark
— Slawek Kaplonski Senior software engineer Red Hat
Hi,
Fix [1] is merged so You can now recheck Your patches if it failed on neutron-tempest-plugin-designate-scenario job earlier.
On 1 Jul 2019, at 14:44, Slawek Kaplonski skaplons@redhat.com wrote:
Hi,
It looks that we (again) have some broken gate. This time it’s problem with neutron-tempest-plugin-designate-scenario job which is failing 100% times. See [1] for details. Patch [2] is proposed so now lets wait until it will be merged and You can than rebase Your neutron patches to make Zuul happy again :)
[1] https://bugs.launchpad.net/devstack/+bug/1834849 [2] https://review.opendev.org/#/c/668447/
— Slawek Kaplonski Senior software engineer Red Hat
[1] https://review.opendev.org/#/c/668447/
— Slawek Kaplonski Senior software engineer Red Hat
participants (3)
-
Clark Boylan
-
Jeremy Stanley
-
Slawek Kaplonski