Utilizzo di Jenkins BUILD NUMBER nel file delle specifiche RPM

È passato molto tempo... e per fortuna non ho sistemi basati su rpm, quindi non posso provarlo.

Puoi passare i parametri a rpmbuild sulla riga di comando

rpmbuild --define="version ${env.BUILD_NUMBER}"

Sarebbe utile pubblicare frammenti delle specifiche e dello script che stai utilizzando per creare l'rpm. Non vuoi che lo script di compilazione modifichi il file delle specifiche, che presumo stia estraendo da un controllo del codice sorgente.

Ho usato il numero di build di Jenkins come 'release' e impacchettato tramite fpm.

Accoppia fpm con alcuni globali forniti da 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.

Ci sono alcune variabili nebulose nel comando di esempio qui sotto, ma $BUILD_NUMBER è quello che sto usando per la versione qui (fpm lo chiama iterazione invece).

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

Nella mia configurazione di Jenkins, ho deciso di ignorare completamente il numero di build per quanto riguarda la numerazione della versione RPM. Invece, utilizzo uno script fatto in casa che genera e tiene traccia delle varie versioni che vengono generate.

Nel mio file delle specifiche:

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

E nello script di build di 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 è un semplice script che mantiene un database basato su file (in formato JSON, per una facile manutenzione). Può gestire l'esecuzione contemporaneamente, quindi non preoccuparti, ma non funzionerà se hai build slave (per quanto ne so, non li uso quindi non posso testare). Puoi trovare il codice sorgente e la documentazione qui.

Il risultato è che ottengo il seguente schema di versione del pacchetto:

# 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:Nota che lo script di build di Jenkins è solo un esempio, la logica dietro la creazione della struttura della directory rpmbuild e il recupero dei nomi dei file .src.rpm e .spec è un po' più complicata.