On Fri, Aug 9, 2019 at 12:44 PM Vojtech Juranek <vjura...@redhat.com> 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 <mzama...@redhat.com> > wrote: > > > Amit Bawer <aba...@redhat.com> writes: > > > > On Thu, Aug 8, 2019 at 2:50 PM Marcin Sobczyk <msobc...@redhat.com> > > > > > > wrote: > > > >> On 8/8/19 1:44 PM, Amit Bawer wrote: > > > >> > > > >> > > > >> > > > >> On Thu, Aug 8, 2019 at 12:48 PM Milan Zamazal <mzama...@redhat.com> > > > > > > wrote: > > > >>> Amit Bawer <aba...@redhat.com> writes: > > > >>> > 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. > > > >>> > > > >>> 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 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/AHPHUZAABAQN > > > WEMD2JQ6WARHJRDTYCPI/> > > > >>> >>>>>>>>>>> -- > > > >>> >>>>>>>>>>> > > > >>> >>>>>>>>>>> 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/W6DUMIUSN5DP > > > UVGUFUNHF2ZALB5I4JPZ/> > > > >>> > _______________________________________________ > > > >>> > 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/MMXGDBHHLMFG > > > XYB4SJM74WTCI3J2UBRQ/> > > > >> _______________________________________________ > > > >> Infra mailing list -- in...@ovirt.org > > > >> To unsubscribe send an email to infra-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/in...@ovirt.org/message/ZUT3AJSGY5L6 > > > 7KGZ5G2JRVIFJHMG6K37/ > > _______________________________________________ > 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/P3AGRBYGUDENDYF3QZ3WMJNGGEEMYQ6D/ >
_______________________________________________ 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/JNUOMVLWXGPZPUEWWGFEAJQNTLWJTRGN/
