On Wed, Feb 27, 2019 at 2:22 PM Barak Korren <bkorren@redhat.com> wrote:
>
>
>
> On Wed, 27 Feb 2019 at 13:00, Dafna Ron <dron@redhat.com> 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@redhat.com> 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/artifact/build-artifacts.el7.x86_64/
>>> 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/artifact/build-artifacts.el7.x86_64/
>>> 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/artifact/build-artifacts.el7.x86_64/
>>>
>>> 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-tests_manual/4159/
>>>
>>> [2] https://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-tests_manual/4159/artifact/exported-artifacts/lago_logs/lago.log
>>>
>>> [3] https://jenkins.ovirt.org/job/ovirt-imageio_standard-check-patch/1007/artifact/build-artifacts.el7.x86_64/
>>> --
>>> Didi
>>> _______________________________________________
>>> Infra mailing list -- infra@ovirt.org
>>> To unsubscribe send an email to infra-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/infra@ovirt.org/message/SGI4LEKEAHCLEYHCINGHALIXDCYJMM6B/
>>
>> _______________________________________________
>> Infra mailing list -- infra@ovirt.org
>> To unsubscribe send an email to infra-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/infra@ovirt.org/message/6PUO7SQHHAKNSGHUBRP5JHH6ZUO2EB3N/
>
>
>
> --
> Barak Korren
> RHV DevOps team , RHCE, RHCi
> Red Hat EMEA
> redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted



--
Didi