On Thu, 28 Feb 2019 at 08:40, Yedidyah Bar David <didi(a)redhat.com> wrote:
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/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.
Its not using the yum repos at all, repoman talks to the jenkins api to get
all the artifacts built by that job.
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
| TRIED. TESTED. TRUSTED. |