[ovirt-devel] Re: [VDSM] Travis builds still fail on .coverage rename

On 6 Jul 2018, at 14:35, Nir Soffer <nsoffer(a)redhat.com&gt; wrote: On Fri, Jul 6, 2018 at 1:12 PM Edward Haas <ehaas(a)redhat.com&gt; wrote: > I do not know if it is relevant or not, but the tests that travis runs > for master are taken from the 4.2 branch. > OVS tests are now running using pytest. > What do you mean by "taken from 4.2 branch"? I mean that the branch checked out is 4.2 and not master. It even says so on the console output.

We run "make check" both in travis (.travis.yml) and ovirt ci (automation/check-patch.sh) > > > On Fri, Jul 6, 2018 at 12:51 AM, Nir Soffer <nsoffer(a)redhat.com&gt; wrote: > >> >> >> On Thu, Jul 5, 2018 at 10:55 PM Nir Soffer <nsoffer(a)redhat.com&gt; wrote: >> >>> On Thu, Jul 5, 2018 at 5:53 PM Nir Soffer <nsoffer(a)redhat.com&gt; wrote: >>> >>>> On Thu, Jul 5, 2018 at 5:43 PM Dan Kenigsberg <danken(a)redhat.com&gt; >>>> wrote: >>>> >>>>> On Thu, Jul 5, 2018 at 2:52 AM, Nir Soffer <nsoffer(a)redhat.com&gt; >>>>> wrote: >>>>> > On Wed, Jul 4, 2018 at 1:00 PM Dan Kenigsberg <danken(a)redhat.com&gt; >>>>> wrote: >>>>> >> >>>>> >> On Wed, Jul 4, 2018 at 12:48 PM, Nir Soffer <nsoffer(a)redhat.com&gt; >>>>> wrote: >>>>> >> > Dan, travis build still fail when renaming coverage file even >>>>> after >>>>> >> > your last patch. >>>>> >> > >>>>> >> > >>>>> >> > >>>>> >> > >>>>> ...........................SS.SS.................................................................................................................................................................SS..................................................S.S................................S................................SS.....SS............................................S...............SSS...S.....S.............................................S................................................................SSS............SSSS..SSSSSSSSS.SS.................................................................................................................................................................. >>>>> >> > >>>>> ---------------------------------------------------------------------- >>>>> >> > Ran 1267 tests in 99.239s >>>>> >> > OK (SKIP=63) >>>>> >> > [ -n "$NOSE_WITH_COVERAGE" ] && mv .coverage .coverage-nose-py2 >>>>> >> > make[1]: *** [check] Error 1 >>>>> >> > make[1]: Leaving directory `/vdsm/tests' >>>>> >> > ERROR: InvocationError: '/usr/bin/make -C tests check' >>>>> >> > >>>>> >> > https://travis-ci.org/oVirt/vdsm/jobs/399932012 >>>>> >> > >>>>> >> > Do you have any idea what is wrong there? >>>>> >> > >>>>> >> > Why we don't have any error message from the failed command? >>>>> >> >>>>> >> No idea, nothing pops to mind. >>>>> >> We can revert to the sillier [ -f .coverage ] condition instead of >>>>> >> understanding (yeah, this feels dirty) >>>>> > >>>>> > >>>>> > Thanks, your patch (https://gerrit.ovirt.org/#/c/92813/) fixed this >>>>> > failure. >>>>> > >>>>> > Now we have failures for the pywatch_test, and some network >>>>> > tests. Can someone from network look at this? >>>>> > https://travis-ci.org/nirs/vdsm/builds/400204807 >>>>> >>>>> https://travis-ci.org/nirs/vdsm/jobs/400204808 shows >>>>> >>>>> ConfigNetworkError: (21, 'Executing commands failed: >>>>> ovs-vsctl: cannot create a bridge named vdsmbr_test because a bridge >>>>> named vdsmbr_test already exists') >>>>> >>>>> which I thought was limited to dirty ovirt-ci jenkins slaves. Any idea >>>>> why it shows here? >>>>> >>>> >>>> Maybe one failed test leave dirty host to the next test? >>>> >>> >> network tests fail now only on CentOS now. >> >> >>> >>>> >>>>> py-watch seems to be failing due to missing gdb on the travis image >>>> >>>> >>>>> cmdutils.py 151 DEBUG ./py-watch 0.1 sleep 10 (cwd >>>>> None) >>>>> cmdutils.py 159 DEBUG FAILED: <err> = 'Traceback >>>>> (most recent call last):\n File "./py-watch", line 60, in <module>\n >>>>> dump_trace(watched_proc)\n File "./py-watch", line 32, in >>>>> dump_trace\n \'thread apply all py-bt\'])\n File >>>>> "/usr/lib64/python2.7/site-packages/subprocess32.py", line 575, in >>>>> call\n p = Popen(*popenargs, **kwargs)\n File >>>>> "/usr/lib64/python2.7/site-packages/subprocess32.py", line 822, in >>>>> __init__\n restore_signals, start_new_session)\n File >>>>> "/usr/lib64/python2.7/site-packages/subprocess32.py", line 1567, in >>>>> _execute_child\n raise child_exception_type(errno_num, >>>>> err_msg)\nOSError: [Errno 2] No such file or directory: \'gdb\'\n'; >>>>> <rc> = 1 >>>>> >>>> >>>> Cool, easy fix. >>>> >>> >>> Fixed by https://gerrit.ovirt.org/#/c/92846/ >>> >> >> Fedora 28 build is green with this change: >> https://travis-ci.org/nirs/vdsm/jobs/400549561 >> >> >> >> ___________________________________ summary ____________________________________ >> tests: commands succeeded >> storage-py27: commands succeeded >> storage-py36: commands succeeded >> lib-py27: commands succeeded >> lib-py36: commands succeeded >> network-py27: commands succeeded >> network-py36: commands succeeded >> virt-py27: commands succeeded >> virt-py36: commands succeeded >> congratulations :) >> >> >> >>> >>>> >>>> >>>>> Nir, could you remind me what is "ERROR: InterpreterNotFound: >>>>> python3.6" and how can we avoid it? it keeps distracting during >>>>> debugging test failures. >>>>> >>>> >>>> We can avoid it in travis using env matrix. >>>> >>>> Currently we run "make check" which run all the the tox envs >>>> (e.g. storage-py27,storage-py36) regardless of the build type. This is >>>> good >>>> for manual usage when you don't know which python version is available >>>> on a developer machine. For example if I have python 3.7 installed, >>>> maybe >>>> I like to test. >>>> >>>> We can change this so we will test only the *-py27 on centos, and both >>>> *-py27 and *-py36 on Fedora. >>>> >>>> We can do the same in ovirt CI but it will be harder, we don't have a >>>> declerative >>>> way to configure this. >>>> >>> >>> Fixed all builds using --enable-python3: >>> https://gerrit.ovirt.org/#/c/92847/ >>> >> >> Here is an example from CentOS build - no false errors. >> >> ___________________________________ summary ____________________________________ >> tests: commands succeeded >> storage-py27: commands succeeded >> lib-py27: commands succeeded >> ERROR: network-py27: commands failed >> virt-py27: commands succeeded >> make: *** [tests] Error 1 >> make: *** Waiting for unfinished jobs.... >> ___________________________________ summary ____________________________________ >> pylint: commands succeeded >> congratulations :) >> >> >> >> >>> >>> Nir >>> >> >