Weakness of repos in OST

Hi, from my point of view, we are not testing the repos in OST, because we manage the packages manually. The clean way would be installing something like https://resources.ovirt.org/pub/yum-repo/ovirt-release43-pre.rpm But this would download each package multiple times each run. Maybe a way to test the repos would be an OST which bypasses lago's repo management. What is your view on this? Dominik

On Tue, 25 Jun 2019 at 12:08, Dominik Holler <dholler@redhat.com> wrote:
Hi, from my point of view, we are not testing the repos in OST, because we manage the packages manually. The clean way would be installing something like https://resources.ovirt.org/pub/yum-repo/ovirt-release43-pre.rpm But this would download each package multiple times each run.
Those repos get created too late for most OST runs that need to test pre-released code. Maybe a way to test the repos would be an OST which bypasses
lago's repo management. What is your view on this? Dominik
Bypassing Lagos repo management means that you would get unreliable tests because you allow outside access during the test run. We had a series of issues in DS CI last week to remind us why this is not a good idea in the long run... The right way to do this IMO is to to have code in OST that extracts the repo configuration files from the *-release*.rpm and plugs them into the existing repo handling code.
_______________________________________________ Devel mailing list -- devel@ovirt.org To unsubscribe send an email to devel-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/devel@ovirt.org/message/7STOCII42CP5ME...
-- Barak Korren RHV DevOps team , RHCE, RHCi Red Hat EMEA redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
participants (2)
-
Barak Korren
-
Dominik Holler