Re: CI: vdsm-standard-check-patch fails

On Thu, Aug 8, 2019 at 12:48 PM Milan Zamazal <mzamazal(a)redhat.com <mailto:mzamazal@redhat.com>> wrote: Amit Bawer <abawer(a)redhat.com <mailto:abawer@redhat.com>> writes: > On Wed, Aug 7, 2019 at 3:14 PM Nir Soffer <nsoffer(a)redhat.com <mailto:nsoffer@redhat.com>> wrote: > >> On Wed, Aug 7, 2019 at 3:06 PM Amit Bawer <abawer(a)redhat.com <mailto:abawer@redhat.com>> wrote: >> >>> >>> >>> On Wed, Aug 7, 2019 at 2:53 PM Nir Soffer <nsoffer(a)redhat.com <mailto:nsoffer@redhat.com>> wrote: >>> >>>> On Wed, Aug 7, 2019 at 1:23 PM Amit Bawer <abawer(a)redhat.com <mailto:abawer@redhat.com>> wrote: >>>> >>>>> >>>>> >>>>> On Wed, Aug 7, 2019 at 11:19 AM Amit Bawer <abawer(a)redhat.com <mailto:abawer@redhat.com>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Tue, Aug 6, 2019 at 5:07 PM Nir Soffer <nsoffer(a)redhat.com <mailto:nsoffer@redhat.com>> wrote: >>>>>> >>>>>>> On Tue, Aug 6, 2019 at 5:01 PM Amit Bawer <abawer(a)redhat.com <mailto:abawer@redhat.com>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Aug 6, 2019 at 4:58 PM Nir Soffer <nsoffer(a)redhat.com <mailto:nsoffer@redhat.com>> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On Tue, Aug 6, 2019 at 11:27 AM Amit Bawer <abawer(a)redhat.com <mailto:abawer@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.

> 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 <amarchuk(a)redhat.com <mailto:amarchuk@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... >>>>>> >>>>>> >>>>>>> >>>>>>> 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 <eedri(a)redhat.com <mailto:eedri@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 <abawer(a)redhat.com <mailto:abawer@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(a)ovirt.org <mailto:devel@ovirt.org> >>>>>>>>>>>> To unsubscribe send an email to devel-leave(a)ovirt.org <mailto:devel-leave@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/AHPHUZAABAQ... >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>> 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(a)ovirt.org <mailto:devel@ovirt.org> >>>>>>>>>> To unsubscribe send an email to devel-leave(a)ovirt.org <mailto:devel-leave@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/W6DUMIUSN5D... >>>>>>>>>> >>>>>>>>> > _______________________________________________ > Devel mailing list -- devel(a)ovirt.org <mailto:devel@ovirt.org> > To unsubscribe send an email to devel-leave(a)ovirt.org <mailto:devel-leave@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/MMXGDBHHLMF... _______________________________________________ Infra mailing list -- infra(a)ovirt.org To unsubscribe send an email to infra-leave(a)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/infra@ovirt.org/message/ZUT3AJSGY5L...