Es ist lange her... und zum Glück habe ich keine RPM-basierten Systeme, also kann ich das nicht testen.
Sie können Parameter an rpmbuild übergeben auf der Kommandozeile
rpmbuild --define="version ${env.BUILD_NUMBER}"
Es wäre hilfreich, Ausschnitte der Spezifikation und des Skripts zu posten, das Sie zum Erstellen des RPM verwenden. Sie möchten nicht, dass Ihr Build-Skript die Spezifikationsdatei bearbeitet, von der ich annehme, dass sie aus einer Quellcodeverwaltung herausgezogen wird.
Ich habe die Jenkins-Build-Nummer als 'Release' und Paketierung über fpm verwendet.
Koppeln Sie fpm mit einigen Globals, die von Jenkins bereitgestellt werden
# $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.
Es gibt einige nebulöse Variablen im Beispielbefehl unten, aber $BUILD_NUMBER verwende ich für die Version hier (fpm nennt es Iteration stattdessen).
fpm_out=$(fpm -a all -n $real_pkg_name -v $version -t rpm -s dir --iteration $BUILD_NUMBER ./*)
In meinem Jenkins-Setup habe ich mich entschieden, die Build-Nummer in Bezug auf die RPM-Versionsnummerierung vollständig zu umgehen. Stattdessen verwende ich ein hausgemachtes Skript, das die verschiedenen generierten Releases generiert und verfolgt.
In meiner Spezifikationsdatei:
Version: %{_iv_pkg_version}
Release: %{_iv_pkg_release}%{?dist}
Und im Jenkins-Build-Skript:
# 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 ist ein einfaches Skript, das eine dateibasierte Datenbank verwaltet (im JSON-Format für eine einfache Wartung). Es kann damit umgehen, dass es gleichzeitig ausgeführt wird, also keine Sorge, aber es funktioniert nicht, wenn Sie Build-Slaves haben (soweit ich das beurteilen kann, verwende ich sie nicht und kann sie daher nicht testen). Den Quellcode und die Dokumentation finden Sie hier.
Das Ergebnis ist, dass ich das folgende Paketversionierungsschema erhalte:
# 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:Beachten Sie, dass das Jenkins-Build-Skript nur ein Beispiel ist, die Logik hinter dem Erstellen der rpmbuild-Verzeichnisstruktur und dem Abrufen der .src.rpm- und .spec-Dateinamen ist etwas komplizierter.