Использование Jenkins Номер сборки в RPM файле спецификации

Question

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

Не уверен, что если кто-нибудь пытался это раньше или, если это легко, но:

Файл спецификации имеет два уникальных индикаторов для своей версии:

• версия (которая определяет версию программного обеспечения)
• Release (который определяет номер пакета '- если вы строите RPM, он сломан, и построить еще один, вас номер «выпуска»

.

Мне интересно, попытался ли кто-нибудь или знал, как использовать переменную Jenkins $ BUILD_NUMBER для динамического изменения номера Release, тем самым увеличивая число Release каждый раз, когда новая успешная сборка завершается ...?

Answer 1

Это было давно ... и, к счастью, у меня нет систем на основе об/мин, поэтому я не могу это проверить.

Вы можете передать параметры rpmbuild в командной строке rpmbuild --define="version = ${env.BUILD_NUMBER}

Было бы полезно размещать фрагменты спецификации и сценарий, который вы используете для создания оборотов. Вы не хотите, чтобы скрипт сборки редактировал спецификационный файл, который я предполагаю, что он вытаскивает из какого-то элемента управления источником.

Answer 2

Я использовал номер сборки Jenkins в качестве «выпуска» и упаковки через fpm.

Пара FPM с некоторыми глобалов предоставленных Дженкинс

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

Там какая-то туманные переменные в примере ниже, но $BUILD_NUMBER это то, что я использую для выпуска здесь (FPM называет его итерации вместо).

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

Answer 3

В моей установке Jenkins я решил обойти номер сборки в отношении нумерации версий RPM полностью. Вместо этого я использую самодельный скрипт, который генерирует и отслеживает различные выпуски, которые генерируются.

В моем файле спецификации:

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

И в сценарии Дженкинс сборки:

# 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 является простой скрипт, который поддерживает базу данных на основе файлов (в формате JSON, для легкого обслуживания). Он может работать одновременно с запуском, поэтому не стоит беспокоиться, но это не сработает, если у вас есть ведомые устройства (насколько я могу судить, я их не использую, поэтому не могу проверить). Вы можете найти исходный код и документацию here.

В результате я получаю следующую схему пакета управления версиями:

# 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: Обратите внимание, что Дженкинс построить сценарий просто пример, логика создания структуры каталогов rpmbuild и извлечения .src. rpm и .spec имена файлов немного сложнее.