Using Jenkins BUILD NUMBER in RPM spec file

Question

Name:                   My Software
Version:                1.0.5
Release:                1
Summary:                This is my software

Not sure if anyone has tried this before or if it is easy, but:

A spec file has two unique indicators for its version:

• Version (which specifies software version)
• Release (which specifies the package's number - if you build an RPM, it's broken, and build another one, you up the 'Release' number.

I'm wondering if anyone has tried, or knows how, I could use the Jenkins $BUILD_NUMBER variable to dynamically change the Release number, thereby increasing the Release number every time a new successful build completes...?

Answer 1

In my Jenkins setup, I've decided to bypass the build number with regards to the RPM version numbering completely. Instead, I use a home-made script that generates and keeps track of the various releases that are being generated.

In my spec file:

Version:    %{_iv_pkg_version}
Release:    %{_iv_pkg_release}%{?dist}

And in the Jenkins build script:

# Just initialising some variables, and retrieving the release number.
package="$JOB_NAME"
# We use setuptools, so we can query the package version like so.
# Use other means to suit your needs.
pkg_version="$(python setup.py --version)"
pkg_release="$(rpm-release-number.py "$package" "$pkg_version")"

# Creating the src.rpm (ignore the spec file variables)
rpmbuild --define "_iv_pkg_version $pkg_version" \
    --define "_iv_pkg_release $pkg_release" \
    -bs "path/to/my/file.spec"

# Use mock to build the package in a clean chroot
mock -r epel-6-x86_64 --define "_iv_pkg_version $pkg_version" \
    --define "_iv_pkg_release $pkg_release" \
    "path/to/my/file.src.rpm"

rpm-release-number.py is a simple script that maintains a file-based database (in JSON format, for easy maintenance). It can handle being run at the same time, so no worries there, but it won't work if you have build slaves (as far as I can tell, I don't use them so can't test). You can find the source code and documentation here.

The result is that I get the following package versioning scheme:

# Build the same version 3 times
foo-1.1-1
foo-1.1-2
foo-1.1-3
# Increment the version number, and build twice
foo-1.2-1
foo-1.2-2

PS: Note that the Jenkins build script is just an example, the logic behind creating the rpmbuild directory structure and retrieving the .src.rpm and .spec file names is a bit more complicated.

Answer 2

I've been using the Jenkins build number as the 'release' and packaging via fpm.

Couple fpm with some globals provided by Jenkins

# $BUILD_ID - The current build id, such as "2005-08-22_23-59-59" (YYYY-MM-DD_hh-mm-ss)
# $BUILD_NUMBER - The current build number, such as "153"
# $BUILD_TAG - String of jenkins-${JOB_NAME}-${BUILD_NUMBER}. Convenient to put into a resource file, a jar file, etc for easier identification.

There's some nebulous variables in the example command below, but $BUILD_NUMBER is what I'm using for the release here (fpm calls it iteration instead).

fpm_out=$(fpm -a all -n $real_pkg_name -v $version -t rpm -s dir --iteration $BUILD_NUMBER ./*)

Answer 3

It's been a long time... and thankfully I have no rpm based systems so I can't test this.

You can pass parameters to rpmbuild on the commandline rpmbuild --define="version = ${env.BUILD_NUMBER}

It would be helpful to post snippets of the spec and the script you're using to build the rpm. You don't want your build script editing the spec file, which I'm assuming it's pulling out down from some source control.