詹金斯 - 将更新的修订传递给下游工作答案

【问题标题】：Jenkins - passing updated revision to downstream jobs詹金斯 - 将更新的修订传递给下游工作
【发布时间】：2013-09-05 11:31:55
【问题描述】：

我们已将构建系统从 CruiseControl 移至 jenkins，以实现多平台产品。这是一个单一的整体工作：
1. 检查更改
2. 更新属性文件中的产品版本号
3. 提交文件到subversion
4. 将 svn 修订号传递给其他平台以进行本地结帐（性能原因）
5. 构建（C++、Java）
6.测试

在 Jenkins 中，我们将构建和测试分为 2 个作业，构建触发测试。所有平台构建都必须成功才能运行测试。我希望平台 A 上的测试能够在平台 B 上的构建失败的情况下运行，但这是一个不同的问题。

我现在要解决的问题是构建阶段。当 Jenkins 启动时，它会在作业开始时知道存储库的 SVN_REVISION。我们在作业期间在编译之前增加内部版本号，我们需要将这个 svn 修订版传递给下游作业。我们需要确保在所有平台上签出相同的修订版，并且测试作业也签出相同的修订版。编译需要 2-3 小时，测试大约需要 7 小时，因此在构建过程中发生一些新的提交并包含在测试作业中是正常的。由于结帐速度不同，我们还在构建阶段进行了提交，这些提交被包含在一个平台中，而不是其他平台中。

我们已经尝试过参数化触发器插件，它可以传递 SVN_REVISION - 作业开始时的修订，但不传递带有内部版本号的修改文件的修订。我们在其他情况下使用参数化触发器，它可以满足我们的需要。

我正在考虑将 svn 修订号添加到属性文件中的一件事。我可以从其他工作的属性文件中读取修订，假设文件没有被更改，这可能是有风险的。 svn 使用 ':' 分隔属性，IIRC，其他属性使用 '=' 表示 key=value，因为我们还读取了要在 shell 脚本中使用的属性。还有其他的依赖项目，等我回办公室搭建沙盒的时候试试这个（半天的工作）。

有人有什么建议或cmets吗？

【问题讨论】：

标签： svn jenkins

【解决方案1】：

感谢这篇文章和下面的 cmets： https://itisatechiesworld.wordpress.com/jenkins-related-articles/jenkins-configuration/jenkins-passing-a-parameter-from-one-job-to-another/

这是对我有用的答案：

获取参数化触发器插件（如何安装：管理Jenkins->管理插件->可用并检查“参数化触发器插件”并安装，注意我还安装了“环境注入器插件”，这可能也是必要的）
转到 JOB_1 并添加构建后操作（触发其他项目的参数化构建）
键入要构建 JOB_2 的项目
添加参数（预定义参数）
在“参数”框中键入以下内容：SVN_REV=${SVN_REVISION}
应用并保存
最重要的一点：您必须将此参数 (SVN_REV) 添加到 JOB_2
转到并检查“此构建已参数化”并添加“字符串参数”
键入“SVN_REV”（必须同名）并输入默认值 1 或其他任何值
它现在是一个环境变量，要访问它，您只需要 %SVN_REV%
在构建步骤中，您可以编写 echo %SVN_REV%，它将显示 SVN_REVISION。

简而言之（必须在两个作业中指定参数） JOB_1 => SVN_REV=${SVN_REVISION}

JOB_2 => 添加 SVN_REV 作为字符串参数，以访问类型 %SVN_REV%

【讨论】：

这应该是正确的答案。工作正常。只需使用 echo SVN_REV 而不是 %echo SVN_REV% 调用变量
如果下游作业有不同的时间表，这将不起作用，特别是当构建在不规则的时间触发时。

【解决方案2】：

我认为Clone Workspace Plugin 很适合您。它允许您克隆工作区，以便其他作业可以使用它。使用它，我会像这样配置我的工作。

(1) Master Job：查看源码，更新内部版本号，克隆工作空间
(2) 平台 1：使用 #1 中的克隆，为平台 1 构建，为测试平台 1 制作工作区克隆
(3) 平台 2：使用 #1 中的克隆，为平台 2 构建，为测试平台 2 制作工作区克隆
(4) 平台 1 测试：使用来自 #2 的克隆
(5) 平台 2 测试：使用 #3 中的克隆

【讨论】：

【解决方案3】：

我们遇到了类似的问题，我们想在从机上调用作业并传递主机正在使用的 SVN 修订版，以下是我们解决此问题的方法：

1) 使用预定义参数 MASTER_SVN_REVISION 调用子作业并为其分配 SVN_REVISION 值

2) 现在在您在步骤 1 中调用的作业中，使用以下机制来使用 MASTER_SVN_REVISION 的值

【讨论】：

【解决方案4】：

参数化触发器插件中的一个源选项是：

从触发构建的工作区读取的属性文件中的属性

如果您在原始工作区中创建它而不签入，则在触发下游作业之前您将不会有任何更改风险。

【讨论】：

我会调查的。但是，我确实需要检查该项目的构建和测试以及其他项目使用的属性文件。

【解决方案5】：

在你的构建步骤中，你可以写echo %SVN_REV%，它会显示 SVN_REVISION。简而言之（必须在BOTH作业中指定参数）

JOB_1 => SVN_REV=${SVN_REVISION}
JOB_2 => Add SVN_REV as a String Parameter, to access type %SVN_REV%

使用${SVN_REV } 访问。它对我有用。

【讨论】：