I found out what happened here in the 1st run. The build job started at* 18:41:26* and finished at* 18:48:19* while artifacts were archived at* 18:48:18* The test job started at* 18:44:13*, finished at* 19:24:10*, so it had reached the point of trying to download the RPMs at* 18:46:36* so almost two minutes before they actually became available.... (All times are in UTC) Dan, you need to wait for the build job to finish before you can launch the test job... On 9 August 2018 at 12:46, Dan Kenigsberg <danken@redhat.com> wrote:
Hello Barak, Dan.
Repoman indeed expect the link to jenkins job only and cannot work with specific artifact path. So I think the last rerun [1] with just http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on- demand-el7-x86_64/44/ worked on repoman side as I see from lago log, the artifacts were detected and downloaded:
2018-08-08 19:58:14,067::INFO::root::Saving /dev/shm/ost/deployment-network-suite-4.2/default/ internal_repo/default/el7/x86_64/vdsm-4.20.36-11.git9f9bbcc.el7.x86_64.rpm 2018-08-08 19:58:14,068::INFO::root::Saving /dev/shm/ost/deployment-network-suite-4.2/default/ internal_repo/default/el7/noarch/vdsm-api-4.20.36-11. git9f9bbcc.el7.noarch.rpm …
That matches artifact names produced by the job Dan passed as the
On Thu, Aug 9, 2018 at 12:41 PM, Anton Marchukov <amarchuk@redhat.com> wrote: parameter:
vdsm-4.20.36-11.git9f9bbcc.el7.x86_64.rpm vdsm-api-4.20.36-11.git9f9bbcc.el7.noarch.rpm ...
[1] https://jenkins.ovirt.org/job/ovirt-system-tests_manual/3054/
Darn, you are right. The second job did take the correct vdsm. It failed due to a production bug that we need to fix.
On 9 August 2018 at 09:25:40, Dan Kenigsberg (danken@redhat.com) wrote:
On Thu, Aug 9, 2018 at 8:29 AM, Barak Korren wrote:
On 8 August 2018 at 22:53, Dan Kenigsberg wrote:
I've executed http://jenkins.ovirt.org/job/ovirt-system-tests_manual/
using http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on- demand-el7-x86_64/44/artifact/exported-artifacts/ as customer repo.
The custom repo has vdsm-4.20.36-11.git9f9bbcc.el7.x86_64.rpm which I expected would be pulled onto ost hosts. However
http://jenkins.ovirt.org/job/ovirt-system-tests_manual/ 3053/artifact/exported-artifacts/tests.test_vm_ operations/lago-network-suite-4-2-host-0/_var_log/yum.log shows that this was not the case.
Any idea why is that?
I can see the following in lago.log (in the section that includes the repoman log):
2018-08-08 18:47:02,357::INFO::repoman.common.repo::Resolving artifact source http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on- demand-el7-x86_64/44/ 2018-08-08 18:47:02,493::INFO::repoman.common.sources.jenkins:: Parsing jenkins URL: http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on- demand-el7-x86_64/44/ 2018-08-08 18:47:02,493::WARNING::root:: No artifacts found 2018-08-08 18:47:02,493::INFO::root:: Done
The fact that the log says 'Parsing jenkins URL' means that repoman
detects that it is a URL to a Jenkins build, additionally when I run
3053/parameters/ properly the
following locally it seems to download the packages just fine:
repoman ~/tmp/repo add http://jenkins.ovirt.org/job/vdsm_4.2_build-artifacts-on- demand-el7-x86_64/44/
So this looks like a repoman bug. Adding Anton.
@Dan - can you just retry?
I did try again, in https://jenkins.ovirt.org/job/ovirt-system-tests_manual/3054 which failed again. However, this time it has an empty lago.log.
_______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to 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/
PQHTXDZ6SLWI53FRHIOE5HDUI5ZBM4Z6/
-- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
-- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted