Automated builds and releases
--kkRamCq5m5VQq0L6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 * Automate the build process, and the release process, directly getting the code from the repos (no manual build tarballs) * Adopt semantic versioning, it's a lot more meaningful than the current sc= heme and fits very well with the above points 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 h= ave passed through all the tests we have, instead of rebuilding on another env,= at another time, by someone else, and passing only manual testing. wdyt? --=20 David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Tel.: +420 532 294 605 Email: dcaro@redhat.com Web: www.redhat.com RHT Global #: 82-62605 --kkRamCq5m5VQq0L6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVcZDBAAoJEEBxx+HSYmnDT08IAJcqZK4lgNV1DqOTvfXrB7Tl 7f7ceRfBezUVVnwQigvDuUz7LqT9SPO9jaNonFzHHuEiBanaug7W+YUdsFPyIEXF khJriJRocs2brZKFlL4IGfHC1yQGh6FomILAJkIUBWyzo+YJWhtobkfz1346q2dl 8B8k7ReZxTCnrB3Rb+dU0i4XY75IGKX0GFMOHQx9Ws0cFbhQBrqd7vW8svTmuFcY 6mtdzvQBmARqYM/wwkC9lLVUAZ0zlfsEoPAU2JSaSCXNEQkd0cy5XLua1oofUVuv t4epBTRu4RXTwblGwcCqrxC5XUoSerHWM2O7Yv5yaXYa6LP4OXSOy4cvEfju+Zk= =8dph -----END PGP SIGNATURE----- --kkRamCq5m5VQq0L6--
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 05.06.2015 14:06, David Caro wrote:
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
* Automate the build process, and the release process, directly getting the code from the repos (no manual build tarballs)
* Adopt semantic versioning, it's a lot more meaningful than the current scheme and fits very well with the above points
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.
wdyt?
a big +1 from a community member, not so much a coder :-) keep up the good work! kind regards Sven -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQGcBAEBCAAGBQJVcZpWAAoJEAq0kGAWDrql3PcL/jRFRr+dg7gpSFYM9jWWMb06 o4DOfjRmDga0YCPLoHQk1/tZwAHkJqMLSrkrkWk2RWYK9dR0ckaWJ5CIA8OuNA5g et+KCVpVnC5FYwbR1Joo5I3ODgSkPONDsE9JdBn1ClT0JRs4U81Wb5ludZNYdtBo Zxu9va86mPIJNd2B6RDc990XOd0HvTTGxfYtbmiBCwGxKlS6imNkTPUW6HzCVC2w ofL4qLGy9JiV0bHKjdOX1K713BDtqtTXTtiME/tvUqhFJRWSQFdP182ftCEMa/xF I5eGCTc17JDKg3PHbufNCdmQevXuk0PpeFX2QbgRxuGfqkL04RsDW8iTyMfo9men /FImHViJhWkum5xWCZJiNDIPvoNkdKcQndu6J6jWbSuEfrUTPG99etb3VL9/dz4L XM8upOrNnpcVkL1x3SWFUYLs739LEJEaNlZ0R3hWtUWv1D8iu1IjQ2xxWbpjcOAv ccvwyXGV12Uon5F8DWb24y6CQb53WhsBVKY5blYH+Q== =f8Ru -----END PGP SIGNATURE-----
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.
* 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@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
--bygAmIonOAIqBxQB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 06/08, Sandro Bonazzola wrote:
Il 05/06/2015 14:06, David Caro ha scritto:
=20 Hi everyone! =20 =20 In an effort to improve the project workflow and ease the maintenance a= nd improve the quality of the project releases I want to propose start wor= king towards automated builds and releases, the main ideas are the following: =20 =20 * 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 =20 I'm not really comfortable in releasing rpms like ovirt-host-deploy-offli= ne-1.4.0-0.0.master.20150528094853.git7428372.el7.x86_64.rpm as GA release.
=20 =20
=20 * Automate the build process, and the release process, directly getting=
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 ag= ain (creating rpms with the same version that contain different code) or bump t= he tag (making it feasible that the first released version is not the lowest t= ag, for example, that the first release 4.17.* vdsm to be 4.17.5 instead of 4.1= 7.0 because it took 5 retaggings to pass the tests) the
code from the repos (no manual build tarballs) =20 This is fine for me, provided that the automated build start from a tagge= d version and become something like ovirt-host-deploy-offline-1.4.0-1 =20 =20 =20 * Adopt semantic versioning, it's a lot more meaningful than the curren= t scheme and fits very well with the above points =20 No much experience in using semantic versioning, will take a look. =20 =20 =20 =20 =20 This will ease and lower the maintenance and the extra work required by maintainers, release engineers (sandro) and infra itself by making rele= ases as easy as hitting a button at any time. That will allow us to lower the t= ime features and fixes get to the users, and deliver packages and builds th= at 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. =20 +1 =20 =20 =20 wdyt? =20 =20 =20 =20 _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel =20 =20 =20 --=20 Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
--=20 David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Tel.: +420 532 294 605 Email: dcaro@redhat.com Web: www.redhat.com RHT Global #: 82-62605 --bygAmIonOAIqBxQB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVdcB9AAoJEEBxx+HSYmnDmHsIAIEy8IwRuYgVkO+XRo/yja4a DhBp+TsE6rzBjEYQw9Ep2Wfn2SG3kQ4ZpNCAsz5RYNUsXynLfgPxYVZHkkR2Q69M 3uKDaoN8JoiqK/l2O/SAnNoAqzxL+I25F1NfC3Ye9in153St7sZat7swZDV6xteR qFKYiyAvR17BDjtDyVowYzc1fpWkthNrtWNe2nBZ1I6Bhwmgc0PFkzKw2a1w48Dp Qrc8aGyI7iePUYL8py5UbtrA5qgSfWT4LiNmKccVyUY+li5HC34Yw62JzrkK0PaW a7mNK4tC0xfKXMPKcA7mu431CoRLJSMl8+K8VoSW8H2SkbQWEgAvYrBTwZ76ODc= =ck4N -----END PGP SIGNATURE----- --bygAmIonOAIqBxQB--
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@redhat.com> To: "Sandro Bonazzola" <sbonazzo@redhat.com> Cc: devel@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@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@redhat.com Web: www.redhat.com RHT Global #: 82-62605 _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
…
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
+1
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)
I'd favor the solution where we increase the tags until we've got the final build. Having different rpms with the same NVR should not happen. - fabian
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@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@redhat.com Web: www.redhat.com RHT Global #: 82-62605
_______________________________________________ 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
Hey,
* 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
* Automate the build process, and the release process, directly getting the code from the repos (no manual build tarballs)
That is an awesome move, this would really save us some time to do this tiresome work.
* Adopt semantic versioning, it's a lot more meaningful than the current scheme and fits very well with the above points
Could you briefly explain the differences to how we do the versioning today? - fabian
participants (5)
-
David Caro -
Fabian Deutsch -
Max Kovgan -
Sandro Bonazzola -
Sven Kieske