[ovirt-devel] Re: CI: vdsm-standard-check-patch fails

[Amit Bawer]

On Fri, Aug 9, 2019 at 12:44 PM Vojtech Juranek  wrote:

> On čtvrtek 8. srpna 2019 14:57:12 CEST Amit Bawer wrote:
> > its not always applicable. for example like in poc where we need to get
> > same branch working in different envs and not wanting to deal with lots
> of
> > cherry-picks from different branches.
>
> as a workaround you can run tests in Travis which runs tests only for the
> latest commit.


This means fork github's vdsm?


> The flow can be (and I use it) - submit smaller batch of
> patches which are ready


Seems that I would still have to break a side branch into smaller branches
for gerrit topics sake.
And if there are review fixes, i'll have to make sure that both copies are
in sync.


> into gerrit and poke people to review them and merge,
>

In practice I have a single approver, so patches could be waiting for a
while.


> in meantime work on your current branch and push changes for testing into
> Travis.
>
> > On Thu, Aug 8, 2019 at 3:16 PM Milan Zamazal 
> wrote:
> > > Amit Bawer  writes:
> > > > On Thu, Aug 8, 2019 at 2:50 PM Marcin Sobczyk 
> > >
> > > wrote:
> > > >> On 8/8/19 1:44 PM, Amit Bawer wrote:
> > > >>
> > > >>
> > > >>
> > > >> On Thu, Aug 8, 2019 at 12:48 PM Milan Zamazal 
> > >
> > > wrote:
> > > >>> Amit Bawer  writes:
> > > >>> > On Wed, Aug 7, 2019 at 3:14 PM Nir Soffer 
> > >
> > > wrote:
> > > >>> >> On Wed, Aug 7, 2019 at 3:06 PM Amit Bawer 
> > >
> > > wrote:
> > > >>> >>> On Wed, Aug 7, 2019 at 2:53 PM Nir Soffer 
> > >
> > > wrote:
> > > >>>  On Wed, Aug 7, 2019 at 1:23 PM Amit Bawer 
> > >
> > > wrote:
> > > >>> > On Wed, Aug 7, 2019 at 11:19 AM Amit Bawer <
> aba...@redhat.com>
> > > >>>
> > > >>> wrote:
> > > >>> >> On Tue, Aug 6, 2019 at 5:07 PM Nir Soffer <
> nsof...@redhat.com>
> > > >>>
> > > >>> wrote:
> > > >>> >>> On Tue, Aug 6, 2019 at 5:01 PM Amit Bawer <
> aba...@redhat.com>
> > > >>>
> > > >>> wrote:
> > > >>>  On Tue, Aug 6, 2019 at 4:58 PM Nir Soffer <
> nsof...@redhat.com
> > > >>> 
> > > >>>  wrote:
> > > >>> > On Tue, Aug 6, 2019 at 11:27 AM Amit Bawer <
> > >
> > > aba...@redhat.com>
> > >
> > > >>> > wrote:
> > > >>> >> I have seen some improvement: when I re-trigger the CI
> per
> > > >>>
> > > >>> patch I
> > > >>>
> > > >>> >> am able to pass or get the actual test errors if any (if
> > > >>> >> not
> > > >>>
> > > >>> on first try,
> > > >>>
> > > >>> >> then on second one).
> > > >>> >> Probably not a very useful information, but I have
> noticed
> > >
> > > that
> > >
> > > >>> >> when I push 30+ patches at the same
> > > >>> >
> > > >>> > Do not do that, jenkins cannot handle 30 concurrent
> builds,
> > >
> > > and
> > >
> > > >>> is
> > > >>>
> > > >>> > it also bad for reviewers,
> > > >>> > getting several mails about every patch in your chain,
> for
> > >
> > > every
> > >
> > > >>> > rebase.
> > > >>> 
> > > >>>  Is there is a way to prevent CI from running per gerrit
> push
> > > >>>  (without working on 30 different branches) ?
> > > >>> >>>
> > > >>> >>> I don't know about such way.
> > > >>> >>
> > > >>> >> A legit option could be adding the Skip CI plugin to jenkins
> > > >>>
> > > >>> plugins
> > > >>>
> > > >>> >> [1]; with that devs can add "[skip ci]" to their commit
> > > >>> >> messages
> > > >>>
> > > >>> to prevent
> > > >>>
> > > >>> >> jenkins from automatically launching CI upon push.
> > > >>> 
> > > >>>  Do you want to modify the commit message for every patch to
> > > >>>  decide
> > > >>>
> > > >>> if ci
> > > >>>
> > > >>>  should run or not?
> > > >>> >>>
> > > >>> >>> I think that having the option to knowingly disable automated
> CI
> > > >>> >>> in
> > > >>>
> > > >>> some
> > > >>>
> > > >>> >>> cases is useful. We could always re-trigger when time is right
> > > >>> >>> [3].
> > > >>> >>> [3]
> > >
> > > https://jenkins.ovirt.org/login?from=%2Fgerrit_manual_trigger%2F
> > >
> > > >>> >> This is too much work, but I think today we can add a comment to
> > >
> > > gerrit
> > >
> > > >>> >> like
> > > >>> >>
> > > >>> >> ci please test
> > > >>> >>
> > > >>> >> That will trigger a build of this patch.
> > > >>> >
> > > >>> > Indeed, but it leaves the "Continuous-Integration" mark
> untouched in
> > > >>> > gerrit, giving the wrong impression this patch is still CI
> failed.
> > > >>>
> > > >>> No, it updates CI score.  I use it routinely with falsely failed
> > > >>> tests.
> > > >>>
> > > >>> In my experience, CI score may not get updated if there are
> concurrent
> > > >>> builds, such as when you upload a new version of a patch while CI
> is
> > > >>> still running on the previous version.
> > > >>
> > > >> I may have missed something, but i tried "ci build" gerrit comment
> on
> > >
> > > one
> > >
> > > >> of the CI failed patches https://gerrit.ovirt.org/#/c/101357/
> > > >> the CI 

[ovirt-devel] Re: CI: vdsm-standard-check-patch fails

[Vojtech Juranek]

On čtvrtek 8. srpna 2019 14:57:12 CEST Amit Bawer wrote:
> its not always applicable. for example like in poc where we need to get
> same branch working in different envs and not wanting to deal with lots of
> cherry-picks from different branches.

as a workaround you can run tests in Travis which runs tests only for the 
latest commit. The flow can be (and I use it) - submit smaller batch of 
patches which are ready into gerrit and poke people to review them and merge, 
in meantime work on your current branch and push changes for testing into 
Travis.

> On Thu, Aug 8, 2019 at 3:16 PM Milan Zamazal  wrote:
> > Amit Bawer  writes:
> > > On Thu, Aug 8, 2019 at 2:50 PM Marcin Sobczyk 
> > 
> > wrote:
> > >> On 8/8/19 1:44 PM, Amit Bawer wrote:
> > >> 
> > >> 
> > >> 
> > >> On Thu, Aug 8, 2019 at 12:48 PM Milan Zamazal 
> > 
> > wrote:
> > >>> Amit Bawer  writes:
> > >>> > On Wed, Aug 7, 2019 at 3:14 PM Nir Soffer 
> > 
> > wrote:
> > >>> >> On Wed, Aug 7, 2019 at 3:06 PM Amit Bawer 
> > 
> > wrote:
> > >>> >>> On Wed, Aug 7, 2019 at 2:53 PM Nir Soffer 
> > 
> > wrote:
> > >>>  On Wed, Aug 7, 2019 at 1:23 PM Amit Bawer 
> > 
> > wrote:
> > >>> > On Wed, Aug 7, 2019 at 11:19 AM Amit Bawer 
> > >>> 
> > >>> wrote:
> > >>> >> On Tue, Aug 6, 2019 at 5:07 PM Nir Soffer 
> > >>> 
> > >>> wrote:
> > >>> >>> On Tue, Aug 6, 2019 at 5:01 PM Amit Bawer 
> > >>> 
> > >>> wrote:
> > >>>  On Tue, Aug 6, 2019 at 4:58 PM Nir Soffer  > >>>  
> > >>>  wrote:
> > >>> > On Tue, Aug 6, 2019 at 11:27 AM Amit Bawer <
> > 
> > aba...@redhat.com>
> > 
> > >>> > wrote:
> > >>> >> I have seen some improvement: when I re-trigger the CI per
> > >>> 
> > >>> patch I
> > >>> 
> > >>> >> am able to pass or get the actual test errors if any (if
> > >>> >> not
> > >>> 
> > >>> on first try,
> > >>> 
> > >>> >> then on second one).
> > >>> >> Probably not a very useful information, but I have noticed
> > 
> > that
> > 
> > >>> >> when I push 30+ patches at the same
> > >>> > 
> > >>> > Do not do that, jenkins cannot handle 30 concurrent builds,
> > 
> > and
> > 
> > >>> is
> > >>> 
> > >>> > it also bad for reviewers,
> > >>> > getting several mails about every patch in your chain, for
> > 
> > every
> > 
> > >>> > rebase.
> > >>>  
> > >>>  Is there is a way to prevent CI from running per gerrit push
> > >>>  (without working on 30 different branches) ?
> > >>> >>> 
> > >>> >>> I don't know about such way.
> > >>> >> 
> > >>> >> A legit option could be adding the Skip CI plugin to jenkins
> > >>> 
> > >>> plugins
> > >>> 
> > >>> >> [1]; with that devs can add "[skip ci]" to their commit
> > >>> >> messages
> > >>> 
> > >>> to prevent
> > >>> 
> > >>> >> jenkins from automatically launching CI upon push.
> > >>>  
> > >>>  Do you want to modify the commit message for every patch to
> > >>>  decide
> > >>> 
> > >>> if ci
> > >>> 
> > >>>  should run or not?
> > >>> >>> 
> > >>> >>> I think that having the option to knowingly disable automated CI
> > >>> >>> in
> > >>> 
> > >>> some
> > >>> 
> > >>> >>> cases is useful. We could always re-trigger when time is right
> > >>> >>> [3].
> > >>> >>> [3]
> > 
> > https://jenkins.ovirt.org/login?from=%2Fgerrit_manual_trigger%2F
> > 
> > >>> >> This is too much work, but I think today we can add a comment to
> > 
> > gerrit
> > 
> > >>> >> like
> > >>> >> 
> > >>> >> ci please test
> > >>> >> 
> > >>> >> That will trigger a build of this patch.
> > >>> > 
> > >>> > Indeed, but it leaves the "Continuous-Integration" mark untouched in
> > >>> > gerrit, giving the wrong impression this patch is still CI failed.
> > >>> 
> > >>> No, it updates CI score.  I use it routinely with falsely failed
> > >>> tests.
> > >>> 
> > >>> In my experience, CI score may not get updated if there are concurrent
> > >>> builds, such as when you upload a new version of a patch while CI is
> > >>> still running on the previous version.
> > >> 
> > >> I may have missed something, but i tried "ci build" gerrit comment on
> > 
> > one
> > 
> > >> of the CI failed patches https://gerrit.ovirt.org/#/c/101357/
> > >> the CI build passed, but CI indicator is still -1. AFAICT I had no
> > >> other
> > >> CI jobs running at the time.
> > >> 
> > >> "ci build" runs only the "build-artifacts" stage. To affect the score
> > 
> > (and
> > 
> > >> run the tests as a matter of fact) you should use "ci test".
> > > 
> > > Thanks for the clarification, good to know.
> > > So that only leaves the "how do disable automated CI upon gerrit push"
> > > issue.
> > 
> > One solution of the problem might be to have smaller batches of unmerged
> > patches.  If we could review and merge patches faster, it would be less
> > burden for everybody, including CI infrastructure.
> > 
> > >>> > The re-trigger UI takes care for that as well.
> > 

[ovirt-devel] Re: CI: vdsm-standard-check-patch fails

[Milan Zamazal]

Amit Bawer  writes:

> On Thu, Aug 8, 2019 at 2:50 PM Marcin Sobczyk  wrote:
>
>>
>> On 8/8/19 1:44 PM, Amit Bawer wrote:
>>
>>
>>
>> On Thu, Aug 8, 2019 at 12:48 PM Milan Zamazal  wrote:
>>
>>> Amit Bawer  writes:
>>>
>>> > On Wed, Aug 7, 2019 at 3:14 PM Nir Soffer  wrote:
>>> >
>>> >> On Wed, Aug 7, 2019 at 3:06 PM Amit Bawer  wrote:
>>> >>
>>> >>>
>>> >>>
>>> >>> On Wed, Aug 7, 2019 at 2:53 PM Nir Soffer  wrote:
>>> >>>
>>>  On Wed, Aug 7, 2019 at 1:23 PM Amit Bawer  wrote:
>>> 
>>> >
>>> >
>>> > On Wed, Aug 7, 2019 at 11:19 AM Amit Bawer 
>>> wrote:
>>> >
>>> >>
>>> >>
>>> >> On Tue, Aug 6, 2019 at 5:07 PM Nir Soffer 
>>> wrote:
>>> >>
>>> >>> On Tue, Aug 6, 2019 at 5:01 PM Amit Bawer 
>>> wrote:
>>> >>>
>>> 
>>> 
>>>  On Tue, Aug 6, 2019 at 4:58 PM Nir Soffer 
>>>  wrote:
>>> 
>>> > On Tue, Aug 6, 2019 at 11:27 AM Amit Bawer 
>>> > wrote:
>>> >
>>> >> I have seen some improvement: when I re-trigger the CI per
>>> patch I
>>> >> am able to pass or get the actual test errors if any (if not
>>> on first try,
>>> >> then on second one).
>>> >> Probably not a very useful information, but I have noticed that
>>> >> when I push 30+ patches at the same
>>> >>
>>> >
>>> > Do not do that, jenkins cannot handle 30 concurrent builds, and
>>> is
>>> > it also bad for reviewers,
>>> > getting several mails about every patch in your chain, for every
>>> > rebase.
>>> >
>>> 
>>>  Is there is a way to prevent CI from running per gerrit push
>>>  (without working on 30 different branches) ?
>>> 
>>> >>>
>>> >>> I don't know about such way.
>>> >>>
>>> >>
>>> >> A legit option could be adding the Skip CI plugin to jenkins
>>> plugins
>>> >> [1]; with that devs can add "[skip ci]" to their commit messages
>>> to prevent
>>> >> jenkins from automatically launching CI upon push.
>>> >>
>>> >
>>>  Do you want to modify the commit message for every patch to decide
>>> if ci
>>>  should run or not?
>>> 
>>> >>>
>>> >>> I think that having the option to knowingly disable automated CI in
>>> some
>>> >>> cases is useful. We could always re-trigger when time is right [3].
>>> >>> [3] https://jenkins.ovirt.org/login?from=%2Fgerrit_manual_trigger%2F
>>> >>>
>>> >>
>>> >> This is too much work, but I think today we can add a comment to gerrit
>>> >> like
>>> >>
>>> >> ci please test
>>> >>
>>> >> That will trigger a build of this patch.
>>> >>
>>> >
>>> > Indeed, but it leaves the "Continuous-Integration" mark untouched in
>>> > gerrit, giving the wrong impression this patch is still CI failed.
>>>
>>> No, it updates CI score.  I use it routinely with falsely failed tests.
>>>
>>> In my experience, CI score may not get updated if there are concurrent
>>> builds, such as when you upload a new version of a patch while CI is
>>> still running on the previous version.
>>>
>>
>> I may have missed something, but i tried "ci build" gerrit comment on one
>> of the CI failed patches https://gerrit.ovirt.org/#/c/101357/
>> the CI build passed, but CI indicator is still -1. AFAICT I had no other
>> CI jobs running at the time.
>>
>> "ci build" runs only the "build-artifacts" stage. To affect the score (and
>> run the tests as a matter of fact) you should use "ci test".
>>
> Thanks for the clarification, good to know.
> So that only leaves the "how do disable automated CI upon gerrit push"
> issue.

One solution of the problem might be to have smaller batches of unmerged
patches.  If we could review and merge patches faster, it would be less
burden for everybody, including CI infrastructure.

>>> > The re-trigger UI takes care for that as well.
>>> >
>>> >
>>> >>
>>> >>
>>> >>>
>>> >>>
>>> 
>>> > Another option is to emulate the behaviour in the existing gerrit
>>> >> plugin (guess there is already such one in ovirt's jenkins), for
>>> example
>>> >> skipping by a topic regex [2].
>>> >>
>>> >
>>>  Not clear how this will help.
>>> 
>>> >>>
>>> >>> If I make a gerrit topic with some name like "my_feature_skip_ci" I
>>> can
>>> >>> control whether I want to have automated CI for its patches.
>>> >>> When I want to go back to normal I can rename it to "my_feature" and
>>> have
>>> >>> CI per push as usual.
>>> >>>
>>> >>>
>>>  I think a possible solution can be running only the top patch in a
>>>  changeset, same way we have in travis,
>>>  and the same way systems that grab patches from mailing lists work.
>>>  Every post to gerrit will trigger one
>>>  build, instead of one build per patch in the chain.
>>> 
>>> >>>
>>> >>> That could do as well.
>>> >>>
>>> >>>
>>>  Of course this will allow merging broken patches that are fixed by a
>>>  later patch in the chain, which
>>>  is also not 

[ovirt-devel] Re: CI: vdsm-standard-check-patch fails

[Amit Bawer]

On Thu, Aug 8, 2019 at 2:50 PM Marcin Sobczyk  wrote:

>
> On 8/8/19 1:44 PM, Amit Bawer wrote:
>
>
>
> On Thu, Aug 8, 2019 at 12:48 PM Milan Zamazal  wrote:
>
>> Amit Bawer  writes:
>>
>> > On Wed, Aug 7, 2019 at 3:14 PM Nir Soffer  wrote:
>> >
>> >> On Wed, Aug 7, 2019 at 3:06 PM Amit Bawer  wrote:
>> >>
>> >>>
>> >>>
>> >>> On Wed, Aug 7, 2019 at 2:53 PM Nir Soffer  wrote:
>> >>>
>>  On Wed, Aug 7, 2019 at 1:23 PM Amit Bawer  wrote:
>> 
>> >
>> >
>> > On Wed, Aug 7, 2019 at 11:19 AM Amit Bawer 
>> wrote:
>> >
>> >>
>> >>
>> >> On Tue, Aug 6, 2019 at 5:07 PM Nir Soffer 
>> wrote:
>> >>
>> >>> On Tue, Aug 6, 2019 at 5:01 PM Amit Bawer 
>> wrote:
>> >>>
>> 
>> 
>>  On Tue, Aug 6, 2019 at 4:58 PM Nir Soffer 
>>  wrote:
>> 
>> > On Tue, Aug 6, 2019 at 11:27 AM Amit Bawer 
>> > wrote:
>> >
>> >> I have seen some improvement: when I re-trigger the CI per
>> patch I
>> >> am able to pass or get the actual test errors if any (if not
>> on first try,
>> >> then on second one).
>> >> Probably not a very useful information, but I have noticed that
>> >> when I push 30+ patches at the same
>> >>
>> >
>> > Do not do that, jenkins cannot handle 30 concurrent builds, and
>> is
>> > it also bad for reviewers,
>> > getting several mails about every patch in your chain, for every
>> > rebase.
>> >
>> 
>>  Is there is a way to prevent CI from running per gerrit push
>>  (without working on 30 different branches) ?
>> 
>> >>>
>> >>> I don't know about such way.
>> >>>
>> >>
>> >> A legit option could be adding the Skip CI plugin to jenkins
>> plugins
>> >> [1]; with that devs can add "[skip ci]" to their commit messages
>> to prevent
>> >> jenkins from automatically launching CI upon push.
>> >>
>> >
>>  Do you want to modify the commit message for every patch to decide
>> if ci
>>  should run or not?
>> 
>> >>>
>> >>> I think that having the option to knowingly disable automated CI in
>> some
>> >>> cases is useful. We could always re-trigger when time is right [3].
>> >>> [3] https://jenkins.ovirt.org/login?from=%2Fgerrit_manual_trigger%2F
>> >>>
>> >>
>> >> This is too much work, but I think today we can add a comment to gerrit
>> >> like
>> >>
>> >> ci please test
>> >>
>> >> That will trigger a build of this patch.
>> >>
>> >
>> > Indeed, but it leaves the "Continuous-Integration" mark untouched in
>> > gerrit, giving the wrong impression this patch is still CI failed.
>>
>> No, it updates CI score.  I use it routinely with falsely failed tests.
>>
>> In my experience, CI score may not get updated if there are concurrent
>> builds, such as when you upload a new version of a patch while CI is
>> still running on the previous version.
>>
>
> I may have missed something, but i tried "ci build" gerrit comment on one
> of the CI failed patches https://gerrit.ovirt.org/#/c/101357/
> the CI build passed, but CI indicator is still -1. AFAICT I had no other
> CI jobs running at the time.
>
> "ci build" runs only the "build-artifacts" stage. To affect the score (and
> run the tests as a matter of fact) you should use "ci test".
>
Thanks for the clarification, good to know.
So that only leaves the "how do disable automated CI upon gerrit push"
issue.

>
>
>>
>> > The re-trigger UI takes care for that as well.
>> >
>> >
>> >>
>> >>
>> >>>
>> >>>
>> 
>> > Another option is to emulate the behaviour in the existing gerrit
>> >> plugin (guess there is already such one in ovirt's jenkins), for
>> example
>> >> skipping by a topic regex [2].
>> >>
>> >
>>  Not clear how this will help.
>> 
>> >>>
>> >>> If I make a gerrit topic with some name like "my_feature_skip_ci" I
>> can
>> >>> control whether I want to have automated CI for its patches.
>> >>> When I want to go back to normal I can rename it to "my_feature" and
>> have
>> >>> CI per push as usual.
>> >>>
>> >>>
>>  I think a possible solution can be running only the top patch in a
>>  changeset, same way we have in travis,
>>  and the same way systems that grab patches from mailing lists work.
>>  Every post to gerrit will trigger one
>>  build, instead of one build per patch in the chain.
>> 
>> >>>
>> >>> That could do as well.
>> >>>
>> >>>
>>  Of course this will allow merging broken patches that are fixed by a
>>  later patch in the chain, which
>>  is also not ideal, but it is better given our restricted resources.
>> 
>> >>>
>> >>> We can re-trigger CI manually in this case as part of the verification
>> >>> process.
>> >>>
>> >>
>> >>>
>>  +Anton Marchukov   I have been told you might
>> be
>> > familiar with a similar solution.
>> >
>> >>
>> >> [1] https://plugins.jenkins.io/ci-skip
>> >> 

[ovirt-devel] Re: CI: vdsm-standard-check-patch fails

[Marcin Sobczyk]

On 8/8/19 1:44 PM, Amit Bawer wrote:



On Thu, Aug 8, 2019 at 12:48 PM Milan Zamazal > wrote:


Amit Bawer mailto:aba...@redhat.com>> writes:

> On Wed, Aug 7, 2019 at 3:14 PM Nir Soffer mailto:nsof...@redhat.com>> wrote:
>
>> On Wed, Aug 7, 2019 at 3:06 PM Amit Bawer mailto:aba...@redhat.com>> wrote:
>>
>>>
>>>
>>> On Wed, Aug 7, 2019 at 2:53 PM Nir Soffer mailto:nsof...@redhat.com>> wrote:
>>>
 On Wed, Aug 7, 2019 at 1:23 PM Amit Bawer mailto:aba...@redhat.com>> wrote:

>
>
> On Wed, Aug 7, 2019 at 11:19 AM Amit Bawer
mailto:aba...@redhat.com>> wrote:
>
>>
>>
>> On Tue, Aug 6, 2019 at 5:07 PM Nir Soffer
mailto:nsof...@redhat.com>> wrote:
>>
>>> On Tue, Aug 6, 2019 at 5:01 PM Amit Bawer
mailto:aba...@redhat.com>> wrote:
>>>


 On Tue, Aug 6, 2019 at 4:58 PM Nir Soffer
mailto:nsof...@redhat.com>>
 wrote:

> On Tue, Aug 6, 2019 at 11:27 AM Amit Bawer
mailto:aba...@redhat.com>>
> wrote:
>
>> I have seen some improvement: when I re-trigger the CI
per patch I
>> am able to pass or get the actual test errors if any
(if not on first try,
>> then on second one).
>> Probably not a very useful information, but I have
noticed that
>> when I push 30+ patches at the same
>>
>
> Do not do that, jenkins cannot handle 30 concurrent
builds, and is
> it also bad for reviewers,
> getting several mails about every patch in your chain,
for every
> rebase.
>

 Is there is a way to prevent CI from running per gerrit push
 (without working on 30 different branches) ?

>>>
>>> I don't know about such way.
>>>
>>
>> A legit option could be adding the Skip CI plugin to
jenkins plugins
>> [1]; with that devs can add "[skip ci]" to their commit
messages to prevent
>> jenkins from automatically launching CI upon push.
>>
>
 Do you want to modify the commit message for every patch to
decide if ci
 should run or not?

>>>
>>> I think that having the option to knowingly disable automated
CI in some
>>> cases is useful. We could always re-trigger when time is right
[3].
>>> [3]
https://jenkins.ovirt.org/login?from=%2Fgerrit_manual_trigger%2F
>>>
>>
>> This is too much work, but I think today we can add a comment
to gerrit
>> like
>>
>>     ci please test
>>
>> That will trigger a build of this patch.
>>
>
> Indeed, but it leaves the "Continuous-Integration" mark untouched in
> gerrit, giving the wrong impression this patch is still CI failed.

No, it updates CI score.  I use it routinely with falsely failed
tests.

In my experience, CI score may not get updated if there are concurrent
builds, such as when you upload a new version of a patch while CI is
still running on the previous version.


I may have missed something, but i tried "ci build" gerrit comment on 
one of the CI failed patches https://gerrit.ovirt.org/#/c/101357/
the CI build passed, but CI indicator is still -1. AFAICT I had no 
other CI jobs running at the time.


"ci build" runs only the "build-artifacts" stage. To affect the score 
(and run the tests as a matter of fact) you should use "ci test".





> The re-trigger UI takes care for that as well.
>
>
>>
>>
>>>
>>>

> Another option is to emulate the behaviour in the existing
gerrit
>> plugin (guess there is already such one in ovirt's
jenkins), for example
>> skipping by a topic regex [2].
>>
>
 Not clear how this will help.

>>>
>>> If I make a gerrit topic with some name like
"my_feature_skip_ci" I can
>>> control whether I want to have automated CI for its patches.
>>> When I want to go back to normal I can rename it to
"my_feature" and have
>>> CI per push as usual.
>>>
>>>
 I think a possible solution can be running only the top patch
in a
 changeset, same way we have in travis,
 and the same way systems that grab patches from mailing lists
work.
 Every post to gerrit will trigger one
 build, instead of one build per patch in the chain.

>>>
>>> That could do as well.
>>>
>>>
 Of course this will allow merging broken patches that are
fixed by a
 later patch in the chain, which
 is also not ideal, but it is better given our restricted
resources.

>>>
>>> We can re-trigger CI 

[ovirt-devel] Re: CI: vdsm-standard-check-patch fails

[Amit Bawer]

On Thu, Aug 8, 2019 at 12:48 PM Milan Zamazal  wrote:

> Amit Bawer  writes:
>
> > On Wed, Aug 7, 2019 at 3:14 PM Nir Soffer  wrote:
> >
> >> On Wed, Aug 7, 2019 at 3:06 PM Amit Bawer  wrote:
> >>
> >>>
> >>>
> >>> On Wed, Aug 7, 2019 at 2:53 PM Nir Soffer  wrote:
> >>>
>  On Wed, Aug 7, 2019 at 1:23 PM Amit Bawer  wrote:
> 
> >
> >
> > On Wed, Aug 7, 2019 at 11:19 AM Amit Bawer 
> wrote:
> >
> >>
> >>
> >> On Tue, Aug 6, 2019 at 5:07 PM Nir Soffer 
> wrote:
> >>
> >>> On Tue, Aug 6, 2019 at 5:01 PM Amit Bawer 
> wrote:
> >>>
> 
> 
>  On Tue, Aug 6, 2019 at 4:58 PM Nir Soffer 
>  wrote:
> 
> > On Tue, Aug 6, 2019 at 11:27 AM Amit Bawer 
> > wrote:
> >
> >> I have seen some improvement: when I re-trigger the CI per
> patch I
> >> am able to pass or get the actual test errors if any (if not on
> first try,
> >> then on second one).
> >> Probably not a very useful information, but I have noticed that
> >> when I push 30+ patches at the same
> >>
> >
> > Do not do that, jenkins cannot handle 30 concurrent builds, and
> is
> > it also bad for reviewers,
> > getting several mails about every patch in your chain, for every
> > rebase.
> >
> 
>  Is there is a way to prevent CI from running per gerrit push
>  (without working on 30 different branches) ?
> 
> >>>
> >>> I don't know about such way.
> >>>
> >>
> >> A legit option could be adding the Skip CI plugin to jenkins plugins
> >> [1]; with that devs can add "[skip ci]" to their commit messages to
> prevent
> >> jenkins from automatically launching CI upon push.
> >>
> >
>  Do you want to modify the commit message for every patch to decide if
> ci
>  should run or not?
> 
> >>>
> >>> I think that having the option to knowingly disable automated CI in
> some
> >>> cases is useful. We could always re-trigger when time is right [3].
> >>> [3] https://jenkins.ovirt.org/login?from=%2Fgerrit_manual_trigger%2F
> >>>
> >>
> >> This is too much work, but I think today we can add a comment to gerrit
> >> like
> >>
> >> ci please test
> >>
> >> That will trigger a build of this patch.
> >>
> >
> > Indeed, but it leaves the "Continuous-Integration" mark untouched in
> > gerrit, giving the wrong impression this patch is still CI failed.
>
> No, it updates CI score.  I use it routinely with falsely failed tests.
>
> In my experience, CI score may not get updated if there are concurrent
> builds, such as when you upload a new version of a patch while CI is
> still running on the previous version.
>

I may have missed something, but i tried "ci build" gerrit comment on one
of the CI failed patches https://gerrit.ovirt.org/#/c/101357/
the CI build passed, but CI indicator is still -1. AFAICT I had no other CI
jobs running at the time.


>
> > The re-trigger UI takes care for that as well.
> >
> >
> >>
> >>
> >>>
> >>>
> 
> > Another option is to emulate the behaviour in the existing gerrit
> >> plugin (guess there is already such one in ovirt's jenkins), for
> example
> >> skipping by a topic regex [2].
> >>
> >
>  Not clear how this will help.
> 
> >>>
> >>> If I make a gerrit topic with some name like "my_feature_skip_ci" I can
> >>> control whether I want to have automated CI for its patches.
> >>> When I want to go back to normal I can rename it to "my_feature" and
> have
> >>> CI per push as usual.
> >>>
> >>>
>  I think a possible solution can be running only the top patch in a
>  changeset, same way we have in travis,
>  and the same way systems that grab patches from mailing lists work.
>  Every post to gerrit will trigger one
>  build, instead of one build per patch in the chain.
> 
> >>>
> >>> That could do as well.
> >>>
> >>>
>  Of course this will allow merging broken patches that are fixed by a
>  later patch in the chain, which
>  is also not ideal, but it is better given our restricted resources.
> 
> >>>
> >>> We can re-trigger CI manually in this case as part of the verification
> >>> process.
> >>>
> >>
> >>>
>  +Anton Marchukov   I have been told you might be
> > familiar with a similar solution.
> >
> >>
> >> [1] https://plugins.jenkins.io/ci-skip
> >> [2]
> >>
> https://stackoverflow.com/questions/37807941/how-can-i-get-jenkins-gerrit-trigger-to-ignore-my-ci-users-commits
> >>
> >>
> >>>
> >>> I'm using keeping several small active branches. While you wait for
> >>> reviews on one topic
> >>> you can work on the other branches.
> >>>
> >>>
> >>>
> 
> >
> >> time the AWS connection issue arises constantly.
> >>
> >> On Sun, Aug 4, 2019 at 4:49 PM Eyal Edri 
> wrote:
> >>
> >>> This 

[ovirt-devel] Re: CI: vdsm-standard-check-patch fails

[Milan Zamazal]

Amit Bawer  writes:

> On Wed, Aug 7, 2019 at 3:14 PM Nir Soffer  wrote:
>
>> On Wed, Aug 7, 2019 at 3:06 PM Amit Bawer  wrote:
>>
>>>
>>>
>>> On Wed, Aug 7, 2019 at 2:53 PM Nir Soffer  wrote:
>>>
 On Wed, Aug 7, 2019 at 1:23 PM Amit Bawer  wrote:

>
>
> On Wed, Aug 7, 2019 at 11:19 AM Amit Bawer  wrote:
>
>>
>>
>> On Tue, Aug 6, 2019 at 5:07 PM Nir Soffer  wrote:
>>
>>> On Tue, Aug 6, 2019 at 5:01 PM Amit Bawer  wrote:
>>>


 On Tue, Aug 6, 2019 at 4:58 PM Nir Soffer 
 wrote:

> On Tue, Aug 6, 2019 at 11:27 AM Amit Bawer 
> wrote:
>
>> I have seen some improvement: when I re-trigger the CI per patch I
>> am able to pass or get the actual test errors if any (if not on 
>> first try,
>> then on second one).
>> Probably not a very useful information, but I have noticed that
>> when I push 30+ patches at the same
>>
>
> Do not do that, jenkins cannot handle 30 concurrent builds, and is
> it also bad for reviewers,
> getting several mails about every patch in your chain, for every
> rebase.
>

 Is there is a way to prevent CI from running per gerrit push
 (without working on 30 different branches) ?

>>>
>>> I don't know about such way.
>>>
>>
>> A legit option could be adding the Skip CI plugin to jenkins plugins
>> [1]; with that devs can add "[skip ci]" to their commit messages to 
>> prevent
>> jenkins from automatically launching CI upon push.
>>
>
 Do you want to modify the commit message for every patch to decide if ci
 should run or not?

>>>
>>> I think that having the option to knowingly disable automated CI in some
>>> cases is useful. We could always re-trigger when time is right [3].
>>> [3] https://jenkins.ovirt.org/login?from=%2Fgerrit_manual_trigger%2F
>>>
>>
>> This is too much work, but I think today we can add a comment to gerrit
>> like
>>
>> ci please test
>>
>> That will trigger a build of this patch.
>>
>
> Indeed, but it leaves the "Continuous-Integration" mark untouched in
> gerrit, giving the wrong impression this patch is still CI failed.

No, it updates CI score.  I use it routinely with falsely failed tests.

In my experience, CI score may not get updated if there are concurrent
builds, such as when you upload a new version of a patch while CI is
still running on the previous version.

> The re-trigger UI takes care for that as well.
>
>
>>
>>
>>>
>>>

> Another option is to emulate the behaviour in the existing gerrit
>> plugin (guess there is already such one in ovirt's jenkins), for example
>> skipping by a topic regex [2].
>>
>
 Not clear how this will help.

>>>
>>> If I make a gerrit topic with some name like "my_feature_skip_ci" I can
>>> control whether I want to have automated CI for its patches.
>>> When I want to go back to normal I can rename it to "my_feature" and have
>>> CI per push as usual.
>>>
>>>
 I think a possible solution can be running only the top patch in a
 changeset, same way we have in travis,
 and the same way systems that grab patches from mailing lists work.
 Every post to gerrit will trigger one
 build, instead of one build per patch in the chain.

>>>
>>> That could do as well.
>>>
>>>
 Of course this will allow merging broken patches that are fixed by a
 later patch in the chain, which
 is also not ideal, but it is better given our restricted resources.

>>>
>>> We can re-trigger CI manually in this case as part of the verification
>>> process.
>>>
>>
>>>
 +Anton Marchukov   I have been told you might be
> familiar with a similar solution.
>
>>
>> [1] https://plugins.jenkins.io/ci-skip
>> [2]
>> https://stackoverflow.com/questions/37807941/how-can-i-get-jenkins-gerrit-trigger-to-ignore-my-ci-users-commits
>>
>>
>>>
>>> I'm using keeping several small active branches. While you wait for
>>> reviews on one topic
>>> you can work on the other branches.
>>>
>>>
>>>

>
>> time the AWS connection issue arises constantly.
>>
>> On Sun, Aug 4, 2019 at 4:49 PM Eyal Edri  wrote:
>>
>>> This was reported already and AFAIK its a network issue between
>>> AWS and PHX which is still being investigated.
>>> Evgheni, any insights or update on the issue? should we involve
>>> debugging from amazon side?
>>>
>>> On Sun, Aug 4, 2019 at 4:46 PM Amit Bawer 
>>> wrote:
>>>
 Hi,
 CI seems to fail constantly for unavailable remote gerrit
 repository.
 Example can be seen here:

 https://jenkins.ovirt.org/job/vdsm_standard-check-patch/9415/console
 

[ovirt-devel] Re: CI: vdsm-standard-check-patch fails

[Nir Soffer]

On Wed, Aug 7, 2019 at 3:18 PM Amit Bawer  wrote:

>
>
> On Wed, Aug 7, 2019 at 3:14 PM Nir Soffer  wrote:
>
>> On Wed, Aug 7, 2019 at 3:06 PM Amit Bawer  wrote:
>>
>>>
>>>
>>> On Wed, Aug 7, 2019 at 2:53 PM Nir Soffer  wrote:
>>>
 On Wed, Aug 7, 2019 at 1:23 PM Amit Bawer  wrote:

>
>
> On Wed, Aug 7, 2019 at 11:19 AM Amit Bawer  wrote:
>
>>
>>
>> On Tue, Aug 6, 2019 at 5:07 PM Nir Soffer  wrote:
>>
>>> On Tue, Aug 6, 2019 at 5:01 PM Amit Bawer  wrote:
>>>


 On Tue, Aug 6, 2019 at 4:58 PM Nir Soffer 
 wrote:

> On Tue, Aug 6, 2019 at 11:27 AM Amit Bawer 
> wrote:
>
>> I have seen some improvement: when I re-trigger the CI per patch
>> I am able to pass or get the actual test errors if any (if not on 
>> first
>> try, then on second one).
>> Probably not a very useful information, but I have noticed that
>> when I push 30+ patches at the same
>>
>
> Do not do that, jenkins cannot handle 30 concurrent builds, and is
> it also bad for reviewers,
> getting several mails about every patch in your chain, for every
> rebase.
>

 Is there is a way to prevent CI from running per gerrit push
 (without working on 30 different branches) ?

>>>
>>> I don't know about such way.
>>>
>>
>> A legit option could be adding the Skip CI plugin to jenkins plugins
>> [1]; with that devs can add "[skip ci]" to their commit messages to 
>> prevent
>> jenkins from automatically launching CI upon push.
>>
>
 Do you want to modify the commit message for every patch to decide if
 ci should run or not?

>>>
>>> I think that having the option to knowingly disable automated CI in some
>>> cases is useful. We could always re-trigger when time is right [3].
>>> [3] https://jenkins.ovirt.org/login?from=%2Fgerrit_manual_trigger%2F
>>>
>>
>> This is too much work, but I think today we can add a comment to gerrit
>> like
>>
>> ci please test
>>
>> That will trigger a build of this patch.
>>
>
> Indeed, but it leaves the "Continuous-Integration" mark untouched in
> gerrit, giving the wrong impression this patch is still CI failed. The
> re-trigger UI takes care for that as well.
>

This is a bug in our CI infra that should be fix.



>
>
>>
>>
>>>
>>>

> Another option is to emulate the behaviour in the existing gerrit
>> plugin (guess there is already such one in ovirt's jenkins), for example
>> skipping by a topic regex [2].
>>
>
 Not clear how this will help.

>>>
>>> If I make a gerrit topic with some name like "my_feature_skip_ci" I can
>>> control whether I want to have automated CI for its patches.
>>> When I want to go back to normal I can rename it to "my_feature" and
>>> have CI per push as usual.
>>>
>>>
 I think a possible solution can be running only the top patch in a
 changeset, same way we have in travis,
 and the same way systems that grab patches from mailing lists work.
 Every post to gerrit will trigger one
 build, instead of one build per patch in the chain.

>>>
>>> That could do as well.
>>>
>>>
 Of course this will allow merging broken patches that are fixed by a
 later patch in the chain, which
 is also not ideal, but it is better given our restricted resources.

>>>
>>> We can re-trigger CI manually in this case as part of the verification
>>> process.
>>>
>>
>>>
 +Anton Marchukov   I have been told you might be
> familiar with a similar solution.
>
>>
>> [1] https://plugins.jenkins.io/ci-skip
>> [2]
>> https://stackoverflow.com/questions/37807941/how-can-i-get-jenkins-gerrit-trigger-to-ignore-my-ci-users-commits
>>
>>
>>>
>>> I'm using keeping several small active branches. While you wait for
>>> reviews on one topic
>>> you can work on the other branches.
>>>
>>>
>>>

>
>> time the AWS connection issue arises constantly.
>>
>> On Sun, Aug 4, 2019 at 4:49 PM Eyal Edri 
>> wrote:
>>
>>> This was reported already and AFAIK its a network issue between
>>> AWS and PHX which is still being investigated.
>>> Evgheni, any insights or update on the issue? should we involve
>>> debugging from amazon side?
>>>
>>> On Sun, Aug 4, 2019 at 4:46 PM Amit Bawer 
>>> wrote:
>>>
 Hi,
 CI seems to fail constantly for unavailable remote gerrit
 repository.
 Example can be seen here:

 https://jenkins.ovirt.org/job/vdsm_standard-check-patch/9415/console
 ___
 Devel mailing list -- devel@ovirt.org
 To unsubscribe send an email to 

[ovirt-devel] Re: CI: vdsm-standard-check-patch fails

[Amit Bawer]

On Wed, Aug 7, 2019 at 3:14 PM Nir Soffer  wrote:

> On Wed, Aug 7, 2019 at 3:06 PM Amit Bawer  wrote:
>
>>
>>
>> On Wed, Aug 7, 2019 at 2:53 PM Nir Soffer  wrote:
>>
>>> On Wed, Aug 7, 2019 at 1:23 PM Amit Bawer  wrote:
>>>


 On Wed, Aug 7, 2019 at 11:19 AM Amit Bawer  wrote:

>
>
> On Tue, Aug 6, 2019 at 5:07 PM Nir Soffer  wrote:
>
>> On Tue, Aug 6, 2019 at 5:01 PM Amit Bawer  wrote:
>>
>>>
>>>
>>> On Tue, Aug 6, 2019 at 4:58 PM Nir Soffer 
>>> wrote:
>>>
 On Tue, Aug 6, 2019 at 11:27 AM Amit Bawer 
 wrote:

> I have seen some improvement: when I re-trigger the CI per patch I
> am able to pass or get the actual test errors if any (if not on first 
> try,
> then on second one).
> Probably not a very useful information, but I have noticed that
> when I push 30+ patches at the same
>

 Do not do that, jenkins cannot handle 30 concurrent builds, and is
 it also bad for reviewers,
 getting several mails about every patch in your chain, for every
 rebase.

>>>
>>> Is there is a way to prevent CI from running per gerrit push
>>> (without working on 30 different branches) ?
>>>
>>
>> I don't know about such way.
>>
>
> A legit option could be adding the Skip CI plugin to jenkins plugins
> [1]; with that devs can add "[skip ci]" to their commit messages to 
> prevent
> jenkins from automatically launching CI upon push.
>

>>> Do you want to modify the commit message for every patch to decide if ci
>>> should run or not?
>>>
>>
>> I think that having the option to knowingly disable automated CI in some
>> cases is useful. We could always re-trigger when time is right [3].
>> [3] https://jenkins.ovirt.org/login?from=%2Fgerrit_manual_trigger%2F
>>
>
> This is too much work, but I think today we can add a comment to gerrit
> like
>
> ci please test
>
> That will trigger a build of this patch.
>

Indeed, but it leaves the "Continuous-Integration" mark untouched in
gerrit, giving the wrong impression this patch is still CI failed. The
re-trigger UI takes care for that as well.


>
>
>>
>>
>>>
 Another option is to emulate the behaviour in the existing gerrit
> plugin (guess there is already such one in ovirt's jenkins), for example
> skipping by a topic regex [2].
>

>>> Not clear how this will help.
>>>
>>
>> If I make a gerrit topic with some name like "my_feature_skip_ci" I can
>> control whether I want to have automated CI for its patches.
>> When I want to go back to normal I can rename it to "my_feature" and have
>> CI per push as usual.
>>
>>
>>> I think a possible solution can be running only the top patch in a
>>> changeset, same way we have in travis,
>>> and the same way systems that grab patches from mailing lists work.
>>> Every post to gerrit will trigger one
>>> build, instead of one build per patch in the chain.
>>>
>>
>> That could do as well.
>>
>>
>>> Of course this will allow merging broken patches that are fixed by a
>>> later patch in the chain, which
>>> is also not ideal, but it is better given our restricted resources.
>>>
>>
>> We can re-trigger CI manually in this case as part of the verification
>> process.
>>
>
>>
>>> +Anton Marchukov   I have been told you might be
 familiar with a similar solution.

>
> [1] https://plugins.jenkins.io/ci-skip
> [2]
> https://stackoverflow.com/questions/37807941/how-can-i-get-jenkins-gerrit-trigger-to-ignore-my-ci-users-commits
>
>
>>
>> I'm using keeping several small active branches. While you wait for
>> reviews on one topic
>> you can work on the other branches.
>>
>>
>>
>>>

> time the AWS connection issue arises constantly.
>
> On Sun, Aug 4, 2019 at 4:49 PM Eyal Edri  wrote:
>
>> This was reported already and AFAIK its a network issue between
>> AWS and PHX which is still being investigated.
>> Evgheni, any insights or update on the issue? should we involve
>> debugging from amazon side?
>>
>> On Sun, Aug 4, 2019 at 4:46 PM Amit Bawer 
>> wrote:
>>
>>> Hi,
>>> CI seems to fail constantly for unavailable remote gerrit
>>> repository.
>>> Example can be seen here:
>>>
>>> https://jenkins.ovirt.org/job/vdsm_standard-check-patch/9415/console
>>> ___
>>> Devel mailing list -- devel@ovirt.org
>>> To unsubscribe send an email to devel-le...@ovirt.org
>>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>>> oVirt Code of Conduct:
>>> https://www.ovirt.org/community/about/community-guidelines/
>>> List Archives:
>>> 

[ovirt-devel] Re: CI: vdsm-standard-check-patch fails

[Nir Soffer]

On Wed, Aug 7, 2019 at 3:06 PM Amit Bawer  wrote:

>
>
> On Wed, Aug 7, 2019 at 2:53 PM Nir Soffer  wrote:
>
>> On Wed, Aug 7, 2019 at 1:23 PM Amit Bawer  wrote:
>>
>>>
>>>
>>> On Wed, Aug 7, 2019 at 11:19 AM Amit Bawer  wrote:
>>>


 On Tue, Aug 6, 2019 at 5:07 PM Nir Soffer  wrote:

> On Tue, Aug 6, 2019 at 5:01 PM Amit Bawer  wrote:
>
>>
>>
>> On Tue, Aug 6, 2019 at 4:58 PM Nir Soffer  wrote:
>>
>>> On Tue, Aug 6, 2019 at 11:27 AM Amit Bawer 
>>> wrote:
>>>
 I have seen some improvement: when I re-trigger the CI per patch I
 am able to pass or get the actual test errors if any (if not on first 
 try,
 then on second one).
 Probably not a very useful information, but I have noticed that
 when I push 30+ patches at the same

>>>
>>> Do not do that, jenkins cannot handle 30 concurrent builds, and is
>>> it also bad for reviewers,
>>> getting several mails about every patch in your chain, for every
>>> rebase.
>>>
>>
>> Is there is a way to prevent CI from running per gerrit push (without
>> working on 30 different branches) ?
>>
>
> I don't know about such way.
>

 A legit option could be adding the Skip CI plugin to jenkins plugins
 [1]; with that devs can add "[skip ci]" to their commit messages to prevent
 jenkins from automatically launching CI upon push.

>>>
>> Do you want to modify the commit message for every patch to decide if ci
>> should run or not?
>>
>
> I think that having the option to knowingly disable automated CI in some
> cases is useful. We could always re-trigger when time is right [3].
> [3] https://jenkins.ovirt.org/login?from=%2Fgerrit_manual_trigger%2F
>

This is too much work, but I think today we can add a comment to gerrit like

ci please test

That will trigger a build of this patch.


>
>
>>
>>> Another option is to emulate the behaviour in the existing gerrit plugin
 (guess there is already such one in ovirt's jenkins), for example skipping
 by a topic regex [2].

>>>
>> Not clear how this will help.
>>
>
> If I make a gerrit topic with some name like "my_feature_skip_ci" I can
> control whether I want to have automated CI for its patches.
> When I want to go back to normal I can rename it to "my_feature" and have
> CI per push as usual.
>
>
>> I think a possible solution can be running only the top patch in a
>> changeset, same way we have in travis,
>> and the same way systems that grab patches from mailing lists work. Every
>> post to gerrit will trigger one
>> build, instead of one build per patch in the chain.
>>
>
> That could do as well.
>
>
>> Of course this will allow merging broken patches that are fixed by a
>> later patch in the chain, which
>> is also not ideal, but it is better given our restricted resources.
>>
>
> We can re-trigger CI manually in this case as part of the verification
> process.
>

>
>> +Anton Marchukov   I have been told you might be
>>> familiar with a similar solution.
>>>

 [1] https://plugins.jenkins.io/ci-skip
 [2]
 https://stackoverflow.com/questions/37807941/how-can-i-get-jenkins-gerrit-trigger-to-ignore-my-ci-users-commits


>
> I'm using keeping several small active branches. While you wait for
> reviews on one topic
> you can work on the other branches.
>
>
>
>>
>>>
 time the AWS connection issue arises constantly.

 On Sun, Aug 4, 2019 at 4:49 PM Eyal Edri  wrote:

> This was reported already and AFAIK its a network issue between
> AWS and PHX which is still being investigated.
> Evgheni, any insights or update on the issue? should we involve
> debugging from amazon side?
>
> On Sun, Aug 4, 2019 at 4:46 PM Amit Bawer 
> wrote:
>
>> Hi,
>> CI seems to fail constantly for unavailable remote gerrit
>> repository.
>> Example can be seen here:
>>
>> https://jenkins.ovirt.org/job/vdsm_standard-check-patch/9415/console
>> ___
>> Devel mailing list -- devel@ovirt.org
>> To unsubscribe send an email to devel-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives:
>> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/AHPHUZAABAQNWEMD2JQ6WARHJRDTYCPI/
>>
>
>
> --
>
> Eyal edri
>
> He / Him / His
>
>
> MANAGER
>
> CONTINUOUS PRODUCTIZATION
>
> SYSTEM ENGINEERING
>
> Red Hat 
> 
> phone: +972-9-7692018
> 

[ovirt-devel] Re: CI: vdsm-standard-check-patch fails

[Amit Bawer]

On Wed, Aug 7, 2019 at 11:19 AM Amit Bawer  wrote:

>
>
> On Tue, Aug 6, 2019 at 5:07 PM Nir Soffer  wrote:
>
>> On Tue, Aug 6, 2019 at 5:01 PM Amit Bawer  wrote:
>>
>>>
>>>
>>> On Tue, Aug 6, 2019 at 4:58 PM Nir Soffer  wrote:
>>>
 On Tue, Aug 6, 2019 at 11:27 AM Amit Bawer  wrote:

> I have seen some improvement: when I re-trigger the CI per patch I am
> able to pass or get the actual test errors if any (if not on first try,
> then on second one).
> Probably not a very useful information, but I have noticed that when I
> push 30+ patches at the same
>

 Do not do that, jenkins cannot handle 30 concurrent builds, and is it
 also bad for reviewers,
 getting several mails about every patch in your chain, for every rebase.

>>>
>>> Is there is a way to prevent CI from running per gerrit push (without
>>> working on 30 different branches) ?
>>>
>>
>> I don't know about such way.
>>
>
> A legit option could be adding the Skip CI plugin to jenkins plugins [1];
> with that devs can add "[skip ci]" to their commit messages to prevent
> jenkins from automatically launching CI upon push.
> Another option is to emulate the behaviour in the existing gerrit plugin
> (guess there is already such one in ovirt's jenkins), for example skipping
> by a topic regex [2].
>

+Anton Marchukov   I have been told you might be
familiar with a similar solution.

>
> [1] https://plugins.jenkins.io/ci-skip
> [2]
> https://stackoverflow.com/questions/37807941/how-can-i-get-jenkins-gerrit-trigger-to-ignore-my-ci-users-commits
>
>
>>
>> I'm using keeping several small active branches. While you wait for
>> reviews on one topic
>> you can work on the other branches.
>>
>>
>>
>>>

> time the AWS connection issue arises constantly.
>
> On Sun, Aug 4, 2019 at 4:49 PM Eyal Edri  wrote:
>
>> This was reported already and AFAIK its a network issue between AWS
>> and PHX which is still being investigated.
>> Evgheni, any insights or update on the issue? should we involve
>> debugging from amazon side?
>>
>> On Sun, Aug 4, 2019 at 4:46 PM Amit Bawer  wrote:
>>
>>> Hi,
>>> CI seems to fail constantly for unavailable remote gerrit repository.
>>> Example can be seen here:
>>> https://jenkins.ovirt.org/job/vdsm_standard-check-patch/9415/console
>>> ___
>>> Devel mailing list -- devel@ovirt.org
>>> To unsubscribe send an email to devel-le...@ovirt.org
>>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>>> oVirt Code of Conduct:
>>> https://www.ovirt.org/community/about/community-guidelines/
>>> List Archives:
>>> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/AHPHUZAABAQNWEMD2JQ6WARHJRDTYCPI/
>>>
>>
>>
>> --
>>
>> Eyal edri
>>
>> He / Him / His
>>
>>
>> MANAGER
>>
>> CONTINUOUS PRODUCTIZATION
>>
>> SYSTEM ENGINEERING
>>
>> Red Hat 
>> 
>> phone: +972-9-7692018
>> irc: eedri (on #tlv #rhev-dev #rhev-integ #cp-devel)
>>
> ___
> Devel mailing list -- devel@ovirt.org
> To unsubscribe send an email to devel-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/W6DUMIUSN5DPUVGUFUNHF2ZALB5I4JPZ/
>

___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/O35NRDUFYTSLU3XLQLDZZ5SUM3XUJQ3N/

[ovirt-devel] Re: CI: vdsm-standard-check-patch fails

[Amit Bawer]

On Tue, Aug 6, 2019 at 5:07 PM Nir Soffer  wrote:

> On Tue, Aug 6, 2019 at 5:01 PM Amit Bawer  wrote:
>
>>
>>
>> On Tue, Aug 6, 2019 at 4:58 PM Nir Soffer  wrote:
>>
>>> On Tue, Aug 6, 2019 at 11:27 AM Amit Bawer  wrote:
>>>
 I have seen some improvement: when I re-trigger the CI per patch I am
 able to pass or get the actual test errors if any (if not on first try,
 then on second one).
 Probably not a very useful information, but I have noticed that when I
 push 30+ patches at the same

>>>
>>> Do not do that, jenkins cannot handle 30 concurrent builds, and is it
>>> also bad for reviewers,
>>> getting several mails about every patch in your chain, for every rebase.
>>>
>>
>> Is there is a way to prevent CI from running per gerrit push (without
>> working on 30 different branches) ?
>>
>
> I don't know about such way.
>

A legit option could be adding the Skip CI plugin to jenkins plugins [1];
with that devs can add "[skip ci]" to their commit messages to prevent
jenkins from automatically launching CI upon push.
Another option is to emulate the behaviour in the existing gerrit plugin
(guess there is already such one in ovirt's jenkins), for example skipping
by a topic regex [2].

[1] https://plugins.jenkins.io/ci-skip
[2]
https://stackoverflow.com/questions/37807941/how-can-i-get-jenkins-gerrit-trigger-to-ignore-my-ci-users-commits


>
> I'm using keeping several small active branches. While you wait for
> reviews on one topic
> you can work on the other branches.
>
>
>
>>
>>>
 time the AWS connection issue arises constantly.

 On Sun, Aug 4, 2019 at 4:49 PM Eyal Edri  wrote:

> This was reported already and AFAIK its a network issue between AWS
> and PHX which is still being investigated.
> Evgheni, any insights or update on the issue? should we involve
> debugging from amazon side?
>
> On Sun, Aug 4, 2019 at 4:46 PM Amit Bawer  wrote:
>
>> Hi,
>> CI seems to fail constantly for unavailable remote gerrit repository.
>> Example can be seen here:
>> https://jenkins.ovirt.org/job/vdsm_standard-check-patch/9415/console
>> ___
>> Devel mailing list -- devel@ovirt.org
>> To unsubscribe send an email to devel-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives:
>> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/AHPHUZAABAQNWEMD2JQ6WARHJRDTYCPI/
>>
>
>
> --
>
> Eyal edri
>
> He / Him / His
>
>
> MANAGER
>
> CONTINUOUS PRODUCTIZATION
>
> SYSTEM ENGINEERING
>
> Red Hat 
> 
> phone: +972-9-7692018
> irc: eedri (on #tlv #rhev-dev #rhev-integ #cp-devel)
>
 ___
 Devel mailing list -- devel@ovirt.org
 To unsubscribe send an email to devel-le...@ovirt.org
 Privacy Statement: https://www.ovirt.org/site/privacy-policy/
 oVirt Code of Conduct:
 https://www.ovirt.org/community/about/community-guidelines/
 List Archives:
 https://lists.ovirt.org/archives/list/devel@ovirt.org/message/W6DUMIUSN5DPUVGUFUNHF2ZALB5I4JPZ/

>>>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/FIQNCVGEKADDZ3XC65QYSI5TCCTPEIKS/

[ovirt-devel] Re: CI: vdsm-standard-check-patch fails

[Nir Soffer]

On Tue, Aug 6, 2019 at 5:01 PM Amit Bawer  wrote:

>
>
> On Tue, Aug 6, 2019 at 4:58 PM Nir Soffer  wrote:
>
>> On Tue, Aug 6, 2019 at 11:27 AM Amit Bawer  wrote:
>>
>>> I have seen some improvement: when I re-trigger the CI per patch I am
>>> able to pass or get the actual test errors if any (if not on first try,
>>> then on second one).
>>> Probably not a very useful information, but I have noticed that when I
>>> push 30+ patches at the same
>>>
>>
>> Do not do that, jenkins cannot handle 30 concurrent builds, and is it
>> also bad for reviewers,
>> getting several mails about every patch in your chain, for every rebase.
>>
>
> Is there is a way to prevent CI from running per gerrit push (without
> working on 30 different branches) ?
>

I don't know about such way.

I'm using keeping several small active branches. While you wait for reviews
on one topic
you can work on the other branches.



>
>>
>>> time the AWS connection issue arises constantly.
>>>
>>> On Sun, Aug 4, 2019 at 4:49 PM Eyal Edri  wrote:
>>>
 This was reported already and AFAIK its a network issue between AWS and
 PHX which is still being investigated.
 Evgheni, any insights or update on the issue? should we involve
 debugging from amazon side?

 On Sun, Aug 4, 2019 at 4:46 PM Amit Bawer  wrote:

> Hi,
> CI seems to fail constantly for unavailable remote gerrit repository.
> Example can be seen here:
> https://jenkins.ovirt.org/job/vdsm_standard-check-patch/9415/console
> ___
> Devel mailing list -- devel@ovirt.org
> To unsubscribe send an email to devel-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/AHPHUZAABAQNWEMD2JQ6WARHJRDTYCPI/
>


 --

 Eyal edri

 He / Him / His


 MANAGER

 CONTINUOUS PRODUCTIZATION

 SYSTEM ENGINEERING

 Red Hat 
 
 phone: +972-9-7692018
 irc: eedri (on #tlv #rhev-dev #rhev-integ #cp-devel)

>>> ___
>>> Devel mailing list -- devel@ovirt.org
>>> To unsubscribe send an email to devel-le...@ovirt.org
>>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>>> oVirt Code of Conduct:
>>> https://www.ovirt.org/community/about/community-guidelines/
>>> List Archives:
>>> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/W6DUMIUSN5DPUVGUFUNHF2ZALB5I4JPZ/
>>>
>>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/IMLFBNCO6VQH55I3BMN5MOMMPFA5SBW7/

[ovirt-devel] Re: CI: vdsm-standard-check-patch fails

[Amit Bawer]

On Tue, Aug 6, 2019 at 4:58 PM Nir Soffer  wrote:

> On Tue, Aug 6, 2019 at 11:27 AM Amit Bawer  wrote:
>
>> I have seen some improvement: when I re-trigger the CI per patch I am
>> able to pass or get the actual test errors if any (if not on first try,
>> then on second one).
>> Probably not a very useful information, but I have noticed that when I
>> push 30+ patches at the same
>>
>
> Do not do that, jenkins cannot handle 30 concurrent builds, and is it also
> bad for reviewers,
> getting several mails about every patch in your chain, for every rebase.
>

Is there is a way to prevent CI from running per gerrit push (without
working on 30 different branches) ?

>
>
>> time the AWS connection issue arises constantly.
>>
>> On Sun, Aug 4, 2019 at 4:49 PM Eyal Edri  wrote:
>>
>>> This was reported already and AFAIK its a network issue between AWS and
>>> PHX which is still being investigated.
>>> Evgheni, any insights or update on the issue? should we involve
>>> debugging from amazon side?
>>>
>>> On Sun, Aug 4, 2019 at 4:46 PM Amit Bawer  wrote:
>>>
 Hi,
 CI seems to fail constantly for unavailable remote gerrit repository.
 Example can be seen here:
 https://jenkins.ovirt.org/job/vdsm_standard-check-patch/9415/console
 ___
 Devel mailing list -- devel@ovirt.org
 To unsubscribe send an email to devel-le...@ovirt.org
 Privacy Statement: https://www.ovirt.org/site/privacy-policy/
 oVirt Code of Conduct:
 https://www.ovirt.org/community/about/community-guidelines/
 List Archives:
 https://lists.ovirt.org/archives/list/devel@ovirt.org/message/AHPHUZAABAQNWEMD2JQ6WARHJRDTYCPI/

>>>
>>>
>>> --
>>>
>>> Eyal edri
>>>
>>> He / Him / His
>>>
>>>
>>> MANAGER
>>>
>>> CONTINUOUS PRODUCTIZATION
>>>
>>> SYSTEM ENGINEERING
>>>
>>> Red Hat 
>>> 
>>> phone: +972-9-7692018
>>> irc: eedri (on #tlv #rhev-dev #rhev-integ #cp-devel)
>>>
>> ___
>> Devel mailing list -- devel@ovirt.org
>> To unsubscribe send an email to devel-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives:
>> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/W6DUMIUSN5DPUVGUFUNHF2ZALB5I4JPZ/
>>
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/7GWYIBO65E6BHTVTKYVTLZKBPMTQ4LDC/

[ovirt-devel] Re: CI: vdsm-standard-check-patch fails

[Nir Soffer]

On Tue, Aug 6, 2019 at 11:27 AM Amit Bawer  wrote:

> I have seen some improvement: when I re-trigger the CI per patch I am able
> to pass or get the actual test errors if any (if not on first try, then on
> second one).
> Probably not a very useful information, but I have noticed that when I
> push 30+ patches at the same
>

Do not do that, jenkins cannot handle 30 concurrent builds, and is it also
bad for reviewers,
getting several mails about every patch in your chain, for every rebase.


> time the AWS connection issue arises constantly.
>
> On Sun, Aug 4, 2019 at 4:49 PM Eyal Edri  wrote:
>
>> This was reported already and AFAIK its a network issue between AWS and
>> PHX which is still being investigated.
>> Evgheni, any insights or update on the issue? should we involve debugging
>> from amazon side?
>>
>> On Sun, Aug 4, 2019 at 4:46 PM Amit Bawer  wrote:
>>
>>> Hi,
>>> CI seems to fail constantly for unavailable remote gerrit repository.
>>> Example can be seen here:
>>> https://jenkins.ovirt.org/job/vdsm_standard-check-patch/9415/console
>>> ___
>>> Devel mailing list -- devel@ovirt.org
>>> To unsubscribe send an email to devel-le...@ovirt.org
>>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>>> oVirt Code of Conduct:
>>> https://www.ovirt.org/community/about/community-guidelines/
>>> List Archives:
>>> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/AHPHUZAABAQNWEMD2JQ6WARHJRDTYCPI/
>>>
>>
>>
>> --
>>
>> Eyal edri
>>
>> He / Him / His
>>
>>
>> MANAGER
>>
>> CONTINUOUS PRODUCTIZATION
>>
>> SYSTEM ENGINEERING
>>
>> Red Hat 
>> 
>> phone: +972-9-7692018
>> irc: eedri (on #tlv #rhev-dev #rhev-integ #cp-devel)
>>
> ___
> Devel mailing list -- devel@ovirt.org
> To unsubscribe send an email to devel-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/W6DUMIUSN5DPUVGUFUNHF2ZALB5I4JPZ/
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/WSSEWXCHCU6BYQCHRBMIVKLHEF3JYGYU/

[ovirt-devel] Re: CI: vdsm-standard-check-patch fails

[Amit Bawer]

I have seen some improvement: when I re-trigger the CI per patch I am able
to pass or get the actual test errors if any (if not on first try, then on
second one).
Probably not a very useful information, but I have noticed that when I push
30+ patches at the same time the AWS connection issue arises constantly.

On Sun, Aug 4, 2019 at 4:49 PM Eyal Edri  wrote:

> This was reported already and AFAIK its a network issue between AWS and
> PHX which is still being investigated.
> Evgheni, any insights or update on the issue? should we involve debugging
> from amazon side?
>
> On Sun, Aug 4, 2019 at 4:46 PM Amit Bawer  wrote:
>
>> Hi,
>> CI seems to fail constantly for unavailable remote gerrit repository.
>> Example can be seen here:
>> https://jenkins.ovirt.org/job/vdsm_standard-check-patch/9415/console
>> ___
>> Devel mailing list -- devel@ovirt.org
>> To unsubscribe send an email to devel-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives:
>> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/AHPHUZAABAQNWEMD2JQ6WARHJRDTYCPI/
>>
>
>
> --
>
> Eyal edri
>
> He / Him / His
>
>
> MANAGER
>
> CONTINUOUS PRODUCTIZATION
>
> SYSTEM ENGINEERING
>
> Red Hat 
> 
> phone: +972-9-7692018
> irc: eedri (on #tlv #rhev-dev #rhev-integ #cp-devel)
>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/W6DUMIUSN5DPUVGUFUNHF2ZALB5I4JPZ/

[ovirt-devel] Re: CI: vdsm-standard-check-patch fails

[Eyal Edri]

This was reported already and AFAIK its a network issue between AWS and PHX
which is still being investigated.
Evgheni, any insights or update on the issue? should we involve debugging
from amazon side?

On Sun, Aug 4, 2019 at 4:46 PM Amit Bawer  wrote:

> Hi,
> CI seems to fail constantly for unavailable remote gerrit repository.
> Example can be seen here:
> https://jenkins.ovirt.org/job/vdsm_standard-check-patch/9415/console
> ___
> Devel mailing list -- devel@ovirt.org
> To unsubscribe send an email to devel-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/AHPHUZAABAQNWEMD2JQ6WARHJRDTYCPI/
>


-- 

Eyal edri

He / Him / His


MANAGER

CONTINUOUS PRODUCTIZATION

SYSTEM ENGINEERING

Red Hat 

phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ #cp-devel)
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/WV7EK2AP6DVQNNWQFEGFRAHI6Q25ZAUC/