In one of my previous posts we learned how to build and package our projects as RPM packages. How do we get our shiny packages to our users? If we host our own RPM repository, we can use our extisting CI infrastructure (jenkins in our case) for that. Here are the steps in detail:
Convention for the RPM location in our jobs
To reduce the work needed for our deployment job we define a location where each job puts the RPM artifacts after a successful build. Typically we use something like
$workspace/build_dir for that. Because we are using matrix build for different target plattforms, we need to use the same naming conventions for our job axes, too!
Job for RPM deployment
Because of the above convention we can use one parameterized job to deploy the packages of different build jobs. We use the
JOBNAME of the build job as our only parameter:
First the deploy job needs to get all the rpms from the build job. We can do this using the Copy Artifact plugin like so:
Since we are usually building for several distributions and processor architectures, we have a complete directory tree in our target directory. We are using a small shell script to copy all the packages to our repository using rsync. Finally we can update the remote repository over ssh. See the complete shell script below:
for i in suse-12.2 suse-12.1 suse-11.4 suse-11.3 do rm -rf $i dir32=$i/RPMS/i686 dir64=$i/RPMS/x86_64 mkdir -p $dir32 mkdir -p $dir64 versionlabel=`echo $i | sed 's/[-\.]//g'` if [ -e all_rpms/Architecture\=32bit\,Distribution\=$versionlabel/build_dir/ ] then cp all_rpms/Architecture\=32bit\,Distribution\=$versionlabel/build_dir/* $dir32 fi if [ -e all_rpms/Architecture\=64bit\,Distribution\=$versionlabel/build_dir/ ] then cp all_rpms/Architecture\=64bit\,Distribution\=$versionlabel/build_dir/* $dir64 fi rsync -e "ssh" -avz $i/* root@repository-server:/srv/www/htdocs/repo/$i/ ssh root@repository-server "createrepo /srv/www/htdocs/repo/$i/RPMS" done
With a few small tricks and scripts we can deploy the artifacts of our build jobs to the RPM repository and thus deliver a new software release at the push of a button. You could let the deployment job run automatically after a successful build, but we like to have more control over the actual software we release to our users.