On Wed, Aug 7, 2019 at 3:14 PM Nir Soffer <nsof...@redhat.com> wrote:

> On Wed, Aug 7, 2019 at 3:06 PM Amit Bawer <aba...@redhat.com> wrote:
>
>>
>>
>> On Wed, Aug 7, 2019 at 2:53 PM Nir Soffer <nsof...@redhat.com> wrote:
>>
>>> On Wed, Aug 7, 2019 at 1:23 PM Amit Bawer <aba...@redhat.com> 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. 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 <amarc...@redhat.com>  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 <ee...@redhat.com> 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 <aba...@redhat.com>
>>>>>>>>>> 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 <https://www.redhat.com/>
>>>>>>>>>> <https://red.ht/sig>
>>>>>>>>>> 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/MMXGDBHHLMFGXYB4SJM74WTCI3J2UBRQ/

Reply via email to