
On 23 November 2017 at 09:09, Barak Korren <bkorren@redhat.com> wrote:
On 23 November 2017 at 01:28, Nir Soffer <nsoffer@redhat.com> wrote:
On Thu, Nov 23, 2017 at 12:36 AM Barak Korren <bkorren@redhat.com> wrote:
On 22 November 2017 at 20:50, Nir Soffer <nsoffer@redhat.com> wrote:
Vdsm should be ready now for fc27 and fcraw builds: https://gerrit.ovirt.org/#/c/84368/
How was this verified?
Piotr, can you add more info about this?
Can we enable the builds again?
I'd rather make sure we have proper verification so we don't end up blocking the development again.... I'd would have been great if you'd let us temporarily enable the jobs before merging that patch so we could let them run on it to verify.
I enabled the fc27 project temporarily, and it still fails when building https://gerrit.ovirt.org/#/c/84368/ trying to import ovirt_imageio_common.
The package is specified in the packages file:
$ git grep ovirt-imageio-common automation/*.packages.fc27 automation/check-patch.packages.fc27:ovirt-imageio-common
We use these repos: $ cat automation/check-patch.repos.fc27 tested,http://resources.ovirt.org/repos/ovirt/tested/master/rpm/$distro virt-preview,http://fedorapeople.org/groups/virt/virt-preview/fedora-$releasever/$basearc...
I'm not sure how trustworthy is $releasever when used by mock ($distro works because our wrapper script takes care of that). I'f you have mock runner already running locally with this configuration. please take a look at what you get in /etc/dnf/dnf.conf when you shell into it and ensure we don't end up having the host release in $releasever
The package exists: http://resources.ovirt.org/repos/ovirt/tested/master/rpm/fc27/noarch/ovirt-i...
repoquery is happy: $ repoquery --repofrompath=r,http://resources.ovirt.org/repos/ovirt/tested/master/rpm/fc27 --repoid=r list ovirt-imageio-common ovirt-imageio-common-0:1.2.0-0.201711212128.git9926984.fc27.noarch
Maybe mock caching issue?
00:00:28.127 Using chroot cache = /var/cache/mock/fedora-27-x86_64-a9934b467f29c7317f7dd8f205d66ddd 00:00:28.127 Using chroot dir = /var/lib/mock/fedora-27-x86_64-a9934b467f29c7317f7dd8f205d66ddd-7425
No. This just tells you where the cache would be, not if its actually there already. But yeah, this run actually did use a cached chroot:
00:00:28.767 Start: unpacking root cache 00:01:01.624 Finish: unpacking root cache
I cleaned it from the node and retriggerd, lets see what happens now:
http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc27-x86_64/85/console
Failed again: 00:11:56.063 ----------------------------------------------------------------------------------------------------------------------------------------- 00:11:56.064 TOTAL 49960 25280 49% 00:11:56.064 ---------------------------------------------------------------------- 00:11:56.065 Ran 2547 tests in 307.236s 00:11:56.065 00:11:56.065 FAILED (SKIP=78, failures=4) 00:11:56.065 make[1]: *** [Makefile:1118: check] Error 1 00:11:56.066 make[1]: Leaving directory '/home/jenkins/workspace/vdsm_master_check-patch-fc27-x86_64/vdsm/tests' 00:11:56.066 ERROR: InvocationError: '/usr/bin/make -C tests check' 00:11:56.067 storage-py27 create: /home/jenkins/workspace/vdsm_master_check-patch-fc27-x86_64/vdsm/.tox/storage-py27 00:11:59.803 storage-py27 installdeps: pytest==3.1.2, nose==1.3.7 .... 00:14:06.238 ___________________________________ summary ____________________________________ 00:14:06.238 ERROR: tests: commands failed 00:14:06.238 storage-py27: commands succeeded 00:14:06.238 SKIPPED: storage-py35: InterpreterNotFound: python3.5 00:14:06.239 storage-py36: commands succeeded 00:14:06.239 lib-py27: commands succeeded 00:14:06.264 make: *** [Makefile:1019: tests] Error 1 00:14:06.270 + collect-logs 00:14:06.270 + cp /var/log/vdsm_tests.log /home/jenkins/workspace/vdsm_master_check-patch-fc27-x86_64/vdsm/exported-artifacts/ 00:14:06.280 Took 488 seconds I can't really tell why this failed, also did we use to have the results exported to XUINT? -- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted