[RFE] Add a jenkins job for copying external packages to static repos
Description
Activity
Yedidyah Bar David June 14, 2017 at 1:15 PM
On Wed, Jun 14, 2017 at 3:33 PM, Barak Korren (oVirt JIRA)
That's a good question from oVirt-metrics' perspective.
I am not sure.
For now we wanted something quick and this was the solution - build in
copr, copy to -static.
I am not saying it's the best solution. I did open the other ticket...
I am just suggesting it as a real-life use-case that we should consider when
designing how to compose our repos etc.
–
Didi
Barak Korren June 14, 2017 at 12:33 PM
So how are we going to deal with this feature when targeting Fedora? Maybe we can ask them to just build for Fedora too?
Yedidyah Bar David June 14, 2017 at 12:23 PM
On Wed, Jun 14, 2017 at 3:12 PM, Barak Korren (oVirt JIRA)
IIRC they do build it in centos-opstools, but not for fedora.
–
Didi
Barak Korren June 14, 2017 at 12:12 PM
I'm guessing the copr functionality is based on some existing tools in Fedora and/or CentOS, so perhaps its just a matter of finding out what those are...
As long as the package is going to be an oVirt dependency, and it is not shipped by anyone else, its better to move it through the oVirt CI process.
If the upstream will release official RPMs at some point we can switch to mirroring their repos for the CI system.
Yedidyah Bar David June 14, 2017 at 12:06 PM
On Wed, Jun 14, 2017 at 2:24 PM, Barak Korren (oVirt JIRA)
That's indeed an option.
This specific project is not really part of oVirt, IIUC.
It will be used as part of the common-logging effort, aka
https://github.com/ViaQ .
Actually this was the first time I built a rubygem in copr (and one of the
first few times I built anything. But I did have an account), and it was
as simple as choosing a build type rubygem and passing the link to it.
I don't think we can beat that yet...
–
Didi
Barak Korren June 14, 2017 at 11:24 AM
See the path that the UX team took, they have "adapter" projects that get the dependencies from the upstream sources and then build the ovirt-specific packages from them.
You can have your project run the build in copr, but it should be just as simple to just run the build on our hardware and not depend on an external service.
Yedidyah Bar David June 14, 2017 at 7:32 AM
On Wed, Jun 14, 2017 at 10:15 AM, eedri (oVirt JIRA)
A recent case we had - we wanted newest rubygem-fluent-plugin-viaq_data_model
on all relevant repos. The code is maintained in github/rubygems. I built it
in copr and copied to -static.
Do we want to directly use copr? IIRC we had problems with this in the past.
If you intend to mirror, fine - how? Do we have a framework for this?
–
Didi
Eyal Edri June 14, 2017 at 7:15 AM
I think we need to remove the static repos completely [1], they already
caused problems in the past which are hard to debug sometimes.
We need a very good reason to want to copy packages manually into oVirt
repos,
There should be 2 options:
1. Add a new project via yaml and build-artifacts so the project will be
built as any other oVirt project, and a build will be done on any commit.
2. If this comes from external source, then we should strive to use an
externa repo for it ( which will be mirrored to ovirt-mirrors )
If the use case isn't one of the above we need to understand it and decide
what is the best solution for it, before we start implementing workaround
jobs to deploy static rpms.
[1] https://ovirt-jira.atlassian.net/browse/OVIRT-1097
On Wed, Jun 14, 2017 at 9:56 AM, Yedidyah Bar David (oVirt JIRA) <
–
Eyal edri
ASSOCIATE MANAGER
RHV DevOps
EMEA VIRTUALIZATION R&D
Red Hat EMEA <https://www.redhat.com/>
<https://red.ht/sig> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
Details
Assignee
infrainfraReporter
Yedidyah Bar DavidYedidyah Bar David(Deactivated)Priority
Medium
Details
Details
Assignee
Reporter
Priority
Medium
Description of problem:
Currently, when we want to copy a package from elsewhere to
resources.ovirt.org, we manually run repoman. It will be nice to have
a jenkins job for this - with inputs probably being URLs of source
packages/repos and target versions to copy to:
1. It will not require us anymore to login there and do sensitive
stuff on it directly
2. It will have proper logs, allowing much more easily understand when
a package was added, by whom, and even perhaps why. So better add to
the inputs also 'Notes'.
This is cloned from:
https://bugzilla.redhat.com/show_bug.cgi?id=1455316
Best,
–
Didi