openSUSE:OpenStack and Crowbar development process

Development, testing, and continuous integration (CI) of OpenStack and Crowbar on openSUSE

We use Jenkins to automatically package changes from upstream git repositories into rpms within an openSUSE environment, and if they successfully build and install, Jenkins commits those changes to the Open Build Service (OBS) which then automatically builds and publishes canonical packages and images.

Detailed workflow

Let's start chronologically through the live from a code change to a final package to a final product.

OpenStack

Let's look first at changes to a released OpenStack version (the graph and the text uses the Liberty release for this):

OpenStack is developed on git.openstack.org and once a check-in to Liberty branches occurs, the daily Jenkins trackupstream job checks out the changes, creates a new tar ball, builds and installs the package and if that is successful, submits it to an OBS staging project.

Once all packages and its dependencies are built, Jenkins runs test jobs (e.g. functional tests: cloud-cleanvm. If the new package passes these tests, the package is automatically pushed from the OBS staging project (e.g. Cloud:OpenStack:Liberty:Staging) to the main one (e.g. Cloud:OpenStack:Liberty). All packages are pushed together to make sure that the versions are all compatible.

The openSUSE distributions always ships the latest stable OpenStack clients release (Newton at the time of writing). The package submission workflow for openSUSE is decoupled from regular OpenStack packaging work. To facilitate the openSUSE:Factory development model, packages are prepared in the Cloud:OpenStack:Factory project and submitted regularly to openSUSE:Factory for review and inclusion in the openSUSE development branch (Factory).

Chef

Currently Chef 10 and 11 are both built directly from upstream, in systemsmanagement:chef:10 and systemsmanagement:chef:master respectively. systemsmanagement:chef:10:staging is a branch of systemsmanagement:chef:10 which allows testing of packaging changes without destabilising the overall build. However, since we are not tracking upstream changes on a regular basis, there is no Jenkins job involved here.

Crowbar

Changes are sent to the https://github.com/crowbar upstream repositories via github pull requests. This is gated by manual peer code review, by Travis and by a continuous CI check.

systemsmanagement:crowbar:3.0:staging is closely tracking github upstream, and this process is automated via a Jenkins job called 'crowbar-trackupstream'. Also, Travis CI runs unit tests on the same upstream.