在 RPM 规范文件中使用 Jenkins BUILD NUMBER答案

【问题标题】：Using Jenkins BUILD NUMBER in RPM spec file在 RPM 规范文件中使用 Jenkins BUILD NUMBER
【发布时间】：2013-04-15 20:49:07
【问题描述】：

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

不确定之前是否有人尝试过，或者是否简单，但是：

规范文件有两个唯一的版本指示符：

版本（指定软件版本）
Release（指定软件包的编号 - 如果您构建一个 RPM，它会损坏，而构建另一个 RPM，您会增加“Release”编号。

我想知道是否有人尝试过或知道如何使用 Jenkins $BUILD_NUMBER 变量来动态更改 Release 数字，从而在每次新的成功构建完成时增加 Release 数字... ?

【问题讨论】：

sed -i "s/VERSION/$BUILD_NUMBER/" rpm.spec
您不想 sed .spec 文件...它（应该）受源代码控制，因此构建不应更改它。
试试fpm，80% 的时间都比规范文件好得多！
嗯。将不得不查看fpm。到目前为止，@thekbb 提到的方法已经奏效了。

标签： linux jenkins rpm rpmbuild rpm-spec

【解决方案1】：

已经很久了……幸好我没有基于 rpm 的系统，所以我无法测试这个。

您可以在命令行上将参数传递给rpmbuild

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

发布规范的 sn-ps 和用于构建 rpm 的脚本会很有帮助。您不希望您的构建脚本编辑规范文件，我假设它是从某些源代码控制中提取出来的。

【讨论】：

规范文件在源代码管理中，是的。我了解不需要使用构建脚本更改规范文件中的任何内容。另一方面，每次我们进行构建时，我都必须手动更改规范文件并将其签入，并进行所有其他相关的更改。让它自动改变会让它变得更容易......：\
是的......这就是为什么你让构建传递它，并在规范文件中留下一些虚假值，比如 9.9.9-1 所以很明显构建没有t 注入正确的版本
那行不通。如 rpmbuild 帮助中所述，我尝试了 --define="Release = ${BUILD_NUMBER}" 和 --define="Release ${BUILD_NUMBER}"。
知道了。我不得不将“Release”的值更改为宏。基本上，将行更改为"Release: %{release}"，然后使用您的答案。谢谢！！

【解决方案2】：

我一直使用 Jenkins 内部版本号作为“发布”并通过 fpm 打包。

将 fpm 与 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.

下面的示例命令中有一些模糊的变量，但$BUILD_NUMBER 是我在此处发布使用的（fpm 将其称为迭代）。

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

【讨论】：

【解决方案3】：

在我的 Jenkins 设置中，我决定完全绕过关于 RPM 版本编号的内部版本号。相反，我使用自制脚本来生成并跟踪正在生成的各种版本。

在我的规范文件中：

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

在 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 是一个简单的脚本，用于维护基于文件的数据库（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：请注意，Jenkins 构建脚本只是一个示例，创建 rpmbuild 目录结构和检索 .src.rpm 和 .spec 文件名的逻辑要复杂一些。

【讨论】：

【解决方案4】：

考虑到规范文件可能是第 3 方，我更喜欢对 Release 字段进行预构建 sed 修补：

sed -i 's/^Release:\(\s*\)\(.*\)$/Release:\1%{?_build_num:%{_build_num}.}%{expand:\2}/g' ./path/to/spec
rpmbuild --define '_build_num $BUILD_NUM' -ba ./path/to/spec

这里%{expand:...} 宏用于处理宏定义的版本号，如 Mageia 规范中的版本号：

Release: %mkrel 1

结果字段将是：

Release: %{?_build_num:%{_build_num}.}%{expand:%mkrel 1}

_build_num 宏的条件扩展使规范仍然可用于本地构建。 IE。如果 SRPM 也是由构建系统准备的。但它可以简化为：

sed -i 's/^Release:\(\s*\)\(.*\)$/Release:\1'$BUILD_NUM'.%{expand:\2}/g' ./path/to/spec
rpmbuild -ba ./path/to/spec

【讨论】：