Re: [ovirt-devel] [TIPS] How to get your package released in oVirt

> That's not automation, its just you (human) building the official build in > COPR > rather in jenkins no? It is automated enough for me, I just upload (the equivalent of tagging) the srpm and it builds it for all platforms. It is then automatically released in the project repository.

COPR is not just a build system, it also exposes repositories for projects and you can easily use it from dnf. It is also much easier to use than what we have, because I can have a separate configuration for different releases and distributions. This is much harder when the release is directly tied to the upstream source repository. And I am using upstream in the project source sense here, oVirt is downstream in that sense (as is Fedora or RHEL). Martin On Wed, Jun 22, 2016 at 12:59 PM, Eyal Edri <eedri(a)redhat.com&gt; wrote: > > > On Wed, Jun 22, 2016 at 12:49 PM, Martin Sivak <msivak(a)redhat.com&gt; wrote: >> >> > What I think we should do is to add support that once an official tag is >> > done an official build will be triggered and done. >> > The question is can the official build flow be automated? IIRC it >> > involves >> > using tarball + signing or some other manual work which isn't >> > similar to the way nigthly rpms are built. >> >> Please let it live separately from the main project development >> repository and its tags.. The spec file is also something that might >> be oVirt specific (because Fedora, RHEL and CentOS have a different >> dependencies and packaging requirements..) and should be separated >> from the actual upstream tarball source release. >> >> But a flow similar to distgit would be nice, let me release a >> component any time I want (with the necessary branch based way to >> ensure compatibility) and take the latest from the right branch for a >> compose. > > > That's not automation, its just you (human) building the official build in > COPR > rather in jenkins no? > > Which again leaves us with the problem of maintainer not aware he needs to > builds/not synced/away.... > > If we can reach a common ground for all projects on how to use a single (or > at least a small group) > of automation scripts that will do a formal build, then similar to what we > do with nightlies we can collected > them into a 'pre' repo which is candidate for release. > > > > >> >> The reason I asked about COPR is that I already use it like that, I >> have a special COPR project where I release optimizer bits for 3.5 [2] >> and 3.6 [1] in the distgit fashion. And I have a separate project for >> master tests and will have a separate project for 4.0 rpms. >> >> [1] >> https://copr.fedorainfracloud.org/coprs/msivak/ovirt-optimizer-for-ovirt-... >> [2] >> https://copr.fedorainfracloud.org/coprs/msivak/ovirt-optimizer-for-ovirt-... >> >> >> Martin >> >> >> On Wed, Jun 22, 2016 at 11:38 AM, Eyal Edri <eedri(a)redhat.com&gt; wrote: >> > >> > >> > On Wed, Jun 22, 2016 at 11:21 AM, Martin Sivak <msivak(a)redhat.com&gt; >> > wrote: >> >> >> >> > - you as packager / maintainer should add your build to the release >> >> > configuration file[1] or send an email with the link to your builds >> >> > to >> >> > the >> >> > person handling the release >> >> >> >> Is there a way to automate this? Like giving you the URL of the >> >> release repository in COPR and using whatever latest package you find >> >> there? >> >> >> > >> > What I think we should do is to add support that once an official tag is >> > done an official build will be triggered and done. >> > The question is can the official build flow be automated? IIRC it >> > involves >> > using tarball + signing or some other manual work which isn't >> > similar to the way nigthly rpms are built. >> > >> > >> >> >> >> Martin >> >> >> >> On Wed, Jun 22, 2016 at 9:44 AM, Sandro Bonazzola < sbonazzo(a)redhat.com&gt; >> >> wrote: >> >> > Hi, >> >> > since it seems not clear how to get your package included in a oVirt >> >> > release, here's the procedure: >> >> > - a new build planned is communicated to devel(a)ovirt.org from release >> >> > engineering team >> >> > - you as package maintainer should prepare your package to be >> >> > released >> >> > with >> >> > desired version (configure.ac, spec, whatever) >> >> > - you as packager should build your package in jenkins / koji / copr >> >> > / >> >> > whatever you use to build >> >> > - you as packager / maintainer should add your build to the release >> >> > configuration file[1] or send an email with the link to your builds >> >> > to >> >> > the >> >> > person handling the release >> >> > - if you correctly add your package to conf files, you'll have your >> >> > package >> >> > released and release notes updated. >> >> > >> >> > [1] like in >> >> > https://gerrit.ovirt.org/#/q/project:releng-tools+topic:releases >> >> > >> >> > Thanks >> >> > -- >> >> > Sandro Bonazzola >> >> > Better technology. Faster innovation. Powered by community >> >> > collaboration. >> >> > See how it works at redhat.com >> >> > >> >> > _______________________________________________ >> >> > Devel mailing list >> >> > Devel(a)ovirt.org >> >> > http://lists.ovirt.org/mailman/listinfo/devel >> >> _______________________________________________ >> >> Devel mailing list >> >> Devel(a)ovirt.org >> >> http://lists.ovirt.org/mailman/listinfo/devel >> >> >> >> >> > >> > >> > >> > -- >> > Eyal Edri >> > Associate Manager >> > RHEV DevOps >> > EMEA ENG Virtualization R&D >> > Red Hat Israel >> > >> > phone: +972-9-7692018 >> > irc: eedri (on #tlv #rhev-dev #rhev-integ) > > > > > -- > Eyal Edri > Associate Manager > RHEV DevOps > EMEA ENG Virtualization R&D > Red Hat Israel > > phone: +972-9-7692018 > irc: eedri (on #tlv #rhev-dev #rhev-integ)