Utilizzando Jenkins numero di build nel file spec RPM

Question

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

Non sono sicuro se qualcuno ha provato questo prima o se è facile, ma:

un file di specifica è dotato di due indicatori unici per la sua versione:

• versione (che specifica versione del software)
• di uscita (che specifica il numero del pacchetto - se si costruisce un RPM, si è rotto, e costruire un altro, è il numero di 'uscita'

.

Mi chiedo se qualcuno ha provato, o sa come, potrei usare la variabile BUILD_NUMBER $ Jenkins per modificare dinamicamente il numero Release, aumentando così il numero Release ogni volta che una nuova build di successo completa ...?

Answer 1

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

È possibile passare parametri a rpmbuild sulla riga di comando rpmbuild --define="version = ${env.BUILD_NUMBER}

Sarebbe utile per pubblicare frammenti di spec e lo script che si sta utilizzando per costruire il numero di giri. Non vuoi che lo script di compilazione modifichi il file spec, che presumo stia tirando giù da qualche controllo sorgente.

Answer 2

Ho utilizzato il numero di build Jenkins come "rilascio" e imballaggio tramite fpm.

Coppia FPM con alcune variabili 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 riportato di seguito, ma $BUILD_NUMBER è quello che sto usando per la rilascio qui (FPM chiama iterazione anziché).

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

Answer 3

Nella mia configurazione Jenkins, ho deciso di ignorare il numero di build per quanto riguarda la numerazione delle versioni RPM completamente. Invece, io uso uno script fatto in casa che genera e tiene traccia dei vari rilasci che vengono generati.

Nel mio file spec:

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

E nello script Jenkins costruire:

# 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 nello stesso momento, quindi non ci si preoccupa, ma non funzionerà se si dispone di build slave (per quanto posso dire, non li uso quindi non posso testare). È possibile trovare il codice sorgente e la documentazione here.

Il risultato è che ottengo il seguente schema pacchetto di controllo delle versioni:

# 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: Si noti che la Jenkins costruire script è solo un esempio, la logica che sta dietro la creazione della struttura di directory rpmbuild e recuperare il .src. i nomi di file rpm e .spec sono un po 'più complicati.