Korzystanie Jenkins numer kompilacji w obr./min pliku spec

Question

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

nie wiem, czy ktoś próbował tego wcześniej lub jeśli jest to łatwe, ale:

Plik Spec ma dwa unikalne wskaźniki dla wersji:

• wersja (która określa wersję oprogramowania)
• uwalnianie (który określa liczbę danego pakietu - jeśli zbudować RPM, jest uszkodzony, i zbudować jeszcze jeden, ty się numer „uwolnienia”

.

Zastanawiam się, czy ktoś próbował, czy wie, jak mógłbym użyć zmiennej Jenkins $ BUILD_NUMBER, aby dynamicznie zmienić numer Release, zwiększając w ten sposób numer Release za każdym razem, gdy nowa pomyślna kompilacja zostanie ukończona ...?

Answer 1

To był długi czas ... i na szczęście nie mam systemów opartych na rpm, więc nie mogę tego przetestować.

można przekazać parametry do rpmbuild w linii poleceń rpmbuild --define="version = ${env.BUILD_NUMBER}

Dobrze byłoby, aby opublikować fragmenty specyfikacji i skrypt, którego używasz do budowania rpm. Nie chcesz, aby twój skrypt instalacyjny edytował plik spec, co zakładam, że jest on usuwany z jakiejś kontroli źródła.

Answer 2

Używam numeru kompilacji Jenkins jako "wydania" i opakowania przez fpm.

Para fpm z niektórych globalnych dostarczonych przez Jenkinsa

# $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. 

Jest pewne zmienne Nebulous w przykładzie polecenia poniżej, ale $BUILD_NUMBER to co używam do uwalnianiu tutaj (FPM nazywa iteracji zamiast).

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

Answer 3

W konfiguracji Jenkins zdecydowałem się ominąć numer kompilacji pod względem numerowania wersji RPM. Zamiast tego korzystam z domowego skryptu, który generuje i śledzi różne publikacje, które są generowane.

W moim pliku spec:

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

I w skrypcie Jenkins produkcji:

# 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 jest prosty skrypt, który utrzymuje bazę danych na podstawie pliku (w formacie JSON, dla łatwej konserwacji). Może poradzić sobie z byciem uruchamianym w tym samym czasie, więc nie ma tam żadnych zmartwień, ale nie zadziała, jeśli masz zbudowanych niewolników (o ile mogę powiedzieć, nie używam ich, więc nie mogę przetestować). Możesz znaleźć kod źródłowy i dokumentację here.

Rezultatem jest to, że pojawia się następujący schemat wersjonowania pakiet:

# 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: Należy pamiętać, że Jenkins zbudować skrypt jest tylko przykładem, logika tworzenia struktury katalogów rpmbuild i pobierania .src. Nazwy plików rpm i .spec są nieco bardziej skomplikowane.