On Wed, Feb 27, 2019 at 2:22 PM Barak Korren <bkorren(a)redhat.com> wrote:
On Wed, 27 Feb 2019 at 13:00, Dafna Ron <dron(a)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(a)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...
>> 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...
>>
>> 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,
--
Didi