Thanks, Barak, for finding out my PEBCAK, and sorry for the noise. This might be a very good moment to request a "ci please ost" which would build a project, and on success shoot it into OST. This is a very typical use case, which does not seem terribly hard to implement with a jenkins job, and would make life easier to me and the other developers who love and depend on oVirt CI.
On Thu, Aug 9, 2018 at 1:36 PM, Barak Korren <bkor...@redhat.com> wrote: > 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 <dan...@redhat.com> wrote: >> >> On Thu, Aug 9, 2018 at 12:41 PM, Anton Marchukov <amarc...@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 >> > 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 (dan...@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/3053/parameters/ >> >> >> 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 >> >> > properly >> >> > detects that it is a URL to a Jenkins build, additionally when I run >> >> > 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-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/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 _______________________________________________ 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/THY5E3XBWD52WJMMYSZ4RSCC75ESIPPE/
