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@redhat.com> wrote:
On Wed, Jun 22, 2016 at 12:49 PM, Martin Sivak <msivak@redhat.com> 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-3.6... [2] https://copr.fedorainfracloud.org/coprs/msivak/ovirt-optimizer-for-ovirt-3.5...
Martin
On Wed, Jun 22, 2016 at 11:38 AM, Eyal Edri <eedri@redhat.com> wrote:
On Wed, Jun 22, 2016 at 11:21 AM, Martin Sivak <msivak@redhat.com> 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@redhat.com> 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@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@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Devel mailing list Devel@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)