Re: How to run manual job with standard STDCIV2 build results?

On Wed, Feb 27, 2019 at 2:22 PM Barak Korren <bkorren(a)redhat.com&gt; wrote: > > > > On Wed, 27 Feb 2019 at 13:00, Dafna Ron <dron(a)redhat.com&gt; wrote: >> >> Hi Didi. >> >> We blocked the ability to use external repos a while ago as they were causing a lot of failures in CQ. >> >> Please add the repos you need to the .repos v2 file and then re-run. >> >> Thanks, >> Dafna >> >> >> On Wed, Feb 27, 2019 at 10:43 AM Yedidyah Bar David <didi(a)redhat.com&gt; wrote: >>> >>> Hi all, >>> >>> I run [1] and it fails with [2]: >>> >>> 2019-02-27 08:27:00,821::log_utils.py::__enter__::600::ovirtlago.reposetup::INFO:: >>> # Running repoman: [0m [0m >>> 2019-02-27 08:27:00,822::log_utils.py::__enter__::600::lago.utils::DEBUG::start >>> task:87982007-be04-4d4b-af19-751f85f8df25:Run command: "repoman" >>> "--option=main.on_empty_source=warn" >>> "--option=store.RPMStore.on_wrong_distro=copy_to_all" >>> "--option=store.RPMStore.with_srcrpms=false" >>> "--option=store.RPMStore.with_sources=false" >>> "--option=store.RPMStore.rpm_dir=" >>> "/dev/shm/ost/deployment-upgrade-from-release-suite-master/default/internal_repo/default" >>> "add" "conf:/home/jenkins/workspace/ovirt-system-tests_manual/ovirt-system-tests/upgrade-from-release-suite-master/extra_sources" >>> "/var/lib/lago/ovirt-master-tested-el7:only-missing" >>> "/var/lib/lago/ovirt-master-snapshot-static-el7:only-missing" >>> "/var/lib/lago/glusterfs-5-el7:only-missing" >>> "/var/lib/lago/centos-updates-el7:only-missing" >>> "/var/lib/lago/centos-base-el7:only-missing" >>> "/var/lib/lago/centos-extras-el7:only-missing" >>> "/var/lib/lago/epel-el7:only-missing" >>> "/var/lib/lago/centos-ovirt-4.3-el7:only-missing" >>> "/var/lib/lago/centos-ovirt-common-el7:only-missing" >>> "/var/lib/lago/centos-qemu-ev-testing-el7:only-missing" >>> "/var/lib/lago/centos-opstools-testing-el7:only-missing" >>> "/var/lib/lago/centos-sclo-rh-release-el7:only-missing": >>> 2019-02-27 08:28:08,161::utils.py::_run_command::192::lago.utils::DEBUG::87982007-be04-4d4b-af19-751f85f8df25: >>> command exit with return code: 1 >>> 2019-02-27 08:28:08,161::utils.py::_run_command::197::lago.utils::DEBUG::87982007-be04-4d4b-af19-751f85f8df25: >>> command stderr: 2019-02-27 08:27:01,014::INFO::repoman.cmd:: >>> 2019-02-27 08:27:01,014::INFO::repoman.cmd::Adding artifacts to the >>> repo /dev/shm/ost/deployment-upgrade-from-release-suite-master/default/internal_repo/default >>> 2019-02-27 08:27:01,015::INFO::repoman.common.stores.RPM::Loading repo >>> /dev/shm/ost/deployment-upgrade-from-release-suite-master/default/internal_repo/default >>> 2019-02-27 08:27:01,015::INFO::repoman.common.stores.RPM::Repo >>> /dev/shm/ost/deployment-upgrade-from-release-suite-master/default/internal_repo/default >>> loaded >>> 2019-02-27 08:27:01,015::INFO::repoman.common.stores.iso::Loading repo >>> /dev/shm/ost/deployment-upgrade-from-release-suite-master/default/internal_repo/default >>> 2019-02-27 08:27:01,016::INFO::repoman.common.stores.iso::Repo >>> /dev/shm/ost/deployment-upgrade-from-release-suite-master/default/internal_repo/default >>> loaded >>> 2019-02-27 08:27:01,020::INFO::repoman.common.repo::Resolving artifact >>> source rec: https://jenkins.ovirt.org/job/ovirt-imageio_standard-check-patch/1007/art... >>> 2019-02-27 08:27:01,022::INFO::repoman.common.sources.url::Recursively >>> fetching URL (level 0): >>> https://jenkins.ovirt.org/job/ovirt-imageio_standard-check-patch/1007/art... >>> 2019-02-27 08:28:08,127::ERROR::repoman.cmd::maximum recursion depth >>> exceeded in cmp >>> >>> Perhaps this is a bug, or a result of supplying in CUSTOM_REPOS [3]: >>> >>> rec: https://jenkins.ovirt.org/job/ovirt-imageio_standard-check-patch/1007/art... >>> >>> Is this a bug? If not, what's the correct way to supply a subtree of >>> the exported artifacts of some (standard CI) build? > > > You need to provide the build URL, without any sub paths beneath it. OK. > > the is no way to provide a subset, OK, > not should you need one, Not sure about that, we'll see :-) Your point is that the job will choose only the correct arch of the build I provide, I guess, based on standard yum/rpm logic and/or some wisdom built into CI (lago, reposync, whatever, not sure). I still think that if a job generates 3 yum _repos_, I should be able to use a specific one, even if adding the others should not hurt me.

Trying now with the build url anyway. Thanks, > >>> >>> >>> Thanks, >>> >>> [1] https://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-te... >>> >>> [2] https://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-te... >>> >>> [3] https://jenkins.ovirt.org/job/ovirt-imageio_standard-check-patch/1007/art... >>> -- >>> Didi >>> _______________________________________________ >>> Infra mailing list -- infra(a)ovirt.org >>> To unsubscribe send an email to infra-leave(a)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/infra@ovirt.org/message/SGI4LEKEAHC... >> >> _______________________________________________ >> Infra mailing list -- infra(a)ovirt.org >> To unsubscribe send an email to infra-leave(a)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/infra@ovirt.org/message/6PUO7SQHHAK... > > > > -- > Barak Korren > RHV DevOps team , RHCE, RHCi > Red Hat EMEA > redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted -- Didi