[ovirt-devel] Automated builds and releases

[Fabian Deutsch]

…

> > > 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 at 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 at redhat.com
> Web: www.redhat.com
> RHT Global #: 82-62605
> 
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>