12:36 p.m.
Max Kovgan
Senior Software Engineer
Red Hat - EMEA ENG Virtualization R&D
Tel.: +972 9769 2060
Email: mkovgan [at] redhat [dot] com
Web: http://www.redhat.com
RHT Global #: 82-72060
----- Original Message -----
From: "David Caro" <dcaroest(a)redhat.com>
To: "Sandro Bonazzola" <sbonazzo(a)redhat.com>
Cc: devel(a)ovirt.org
Sent: Monday, June 8, 2015 7:19:09 PM
Subject: Re: [ovirt-devel] Automated builds and releases
On 06/08, Sandro Bonazzola wrote:
Il 05/06/2015 14:06, David Caro ha scritto:
>
> Hi everyone!
>
>
> In an effort to improve the project workflow and ease the maintenance and
> improve the quality of the project releases I want to propose start working
> towards automated builds and releases, the main ideas are the following:
>
>
> * Stop building differently for release and non-release:
> - Building only once, testing what you build and release what you test
> - Don't use two different version strings, one for testing and one for
> release
I'm not really comfortable in releasing rpms like
ovirt-host-deploy-offline-1.4.0-0.0.master.20150528094853.git7428372.el7.x86_64.rpm
as GA release.
This can be automated to don't add the extra info to the release in case of a
tag creation, but that means that you have to run all the testing again when
pushing the tag, ideally it would block the tag creation, so if it fails it
would not tag the build but we don't have any gating system so right now it
would have been done after the tag is pushed, so you'd have to force tag again
(creating rpms with the same version that contain different code) or bump the
tag (making it feasible that the first released version is not the lowest tag,
for example, that the first release 4.17.* vdsm to be 4.17.5 instead of 4.17.0
because it took 5 retaggings to pass the tests)
Extra metadata can be added to the rpm:
branch: master
commit_id: 7428372
so the build passed QE and
1) file names of the rpms can be changed to standard NVR
2) createrepo is running
3) repo is validated repoclosure
>
> * Automate the build process, and the release process, directly getting the
> code from the repos (no manual build tarballs)
This is fine for me, provided that the automated build start from a tagged version and
become something like ovirt-host-deploy-offline-1.4.0-1
>
> * Adopt semantic versioning, it's a lot more meaningful than the current scheme
> and fits very well with the above points
No much experience in using semantic versioning, will take a look.
>
>
>
> This will ease and lower the maintenance and the extra work required by
> maintainers, release engineers (sandro) and infra itself by making releases as
> easy as hitting a button at any time. That will allow us to lower the time
> features and fixes get to the users, and deliver packages and builds that have
> passed through all the tests we have, instead of rebuilding on another env, at
> another time, by someone else, and passing only manual testing.
+1
>
>
> wdyt?
>
>
>
>
> _______________________________________________
> Devel mailing list
> Devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
--
David Caro
Red Hat S.L.
Continuous Integration Engineer - EMEA ENG Virtualization R&D
Tel.: +420 532 294 605
Email: dcaro(a)redhat.com
Web: www.redhat.com
RHT Global #: 82-62605
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel