Cela fait longtemps... et heureusement, je n'ai pas de système basé sur les rpm, donc je ne peux pas tester cela.
Vous pouvez passer des paramètres à rpmbuild en ligne de commande
rpmbuild --define="version ${env.BUILD_NUMBER}"
Il serait utile de publier des extraits de la spécification et du script que vous utilisez pour créer le rpm. Vous ne voulez pas que votre script de construction modifie le fichier de spécification, que je suppose qu'il extrait d'un contrôle de source.
J'ai utilisé le numéro de build Jenkins comme "version" et empaqueté via fpm.
Coupler fpm avec quelques globals fournis par 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.
Il y a quelques variables nébuleuses dans l'exemple de commande ci-dessous, mais $BUILD_NUMBER est ce que j'utilise pour la version ici (fpm l'appelle itération à la place).
fpm_out=$(fpm -a all -n $real_pkg_name -v $version -t rpm -s dir --iteration $BUILD_NUMBER ./*)
Dans ma configuration Jenkins, j'ai décidé de contourner complètement le numéro de build en ce qui concerne la numérotation des versions RPM. Au lieu de cela, j'utilise un script maison qui génère et garde une trace des différentes versions générées.
Dans mon fichier de spécifications :
Version: %{_iv_pkg_version}
Release: %{_iv_pkg_release}%{?dist}
Et dans le script de build Jenkins :
# 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 est un script simple qui gère une base de données basée sur des fichiers (au format JSON, pour une maintenance facile). Il peut gérer l'exécution en même temps, donc pas de soucis là-bas, mais cela ne fonctionnera pas si vous avez des esclaves de construction (pour autant que je sache, je ne les utilise pas, donc je ne peux pas tester). Vous pouvez trouver le code source et la documentation ici.
Le résultat est que j'obtiens le schéma de gestion des versions de package suivant :
# 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 :Notez que le script de construction Jenkins n'est qu'un exemple, la logique derrière la création de la structure de répertoires rpmbuild et la récupération des noms de fichiers .src.rpm et .spec est un peu plus compliquée.