Jenkins - 作业 A 为作业 B 设置内部版本号，而无需从磁盘重新加载项目配置答案

【问题标题】：Jenkins - Job A sets the build number for Job B without reloading project configuration from diskJenkins - 作业 A 为作业 B 设置内部版本号，而无需从磁盘重新加载项目配置
【发布时间】：2020-09-30 16:17:08
【问题描述】：

我想让一个 Jenkins 作业控制另一个作业的内部版本号，但又不想从磁盘重新加载整个项目配置的不便。我已经看到直接更新目标作业的 nextBuildNumber 文件很容易（我可以将其作为作业 A 的构建步骤来执行），但这不会立即生效。重新启动 Jenkins 甚至从磁盘重新加载 Jenkins 配置需要太长时间，并且只能在没有正在进行的构建时完成。

我已经尝试了下面帖子中提到的 groovy 脚本，方法是从 Manage Jenkins > Script Console 运行它。同一篇文章还建议可以将脚本保存为文件并从 CLI 运行。可以从构建步骤运行吗？

我希望作业 A 确定作业 B 的下一个内部版本号并设置它，以便作业 B 可以使用所需的内部版本号运行（在同一天晚些时候）。

https://stackoverflow.com/a/20077362/4306857

也许我应该澄清一下。我对 Groovy 不熟悉，所以我正在研究各种构建步骤选项，例如我有很多经验的“执行 Windows 批处理命令”。我可以看到一个“调用 Gradle 脚本”选项，所以我想知道是否可能有一个插件可以运行 Groovy 脚本？

出现此要求的原因是我们正在为两个不同的平台编译产品。我们希望通过两个作业（A 和 B）几乎同时为两个平台编译代码库，这两个作业都将更新构建中包含的 JIRA 案例。我们认为让这两个作业使用相同的内部版本号运行会减少混乱，因此当我们谈论构建 #75 中解决的特定问题时，我们不必通过说明完整的作业名称来限定它.如果 JOB-A 构建 #75 和 JOB-B 构建 #75 都是在同一天从同一个代码库编译的，我们可以测试和比较两个构建的结果，与构建编号不同步的情况相比，混淆要少得多。

显然，在短期内，我们将使用 Set Next Build Number 插件手动保持内部版本号同步，但我们希望尽可能自动化。

【问题讨论】：

我会更改脚本以使用 readFile 和 writeFile 步骤而不是 Java 流，否则它应该在管道中工作（然后可以从 cli 触发）。我很好奇，你为什么需要这种行为？
谢谢你的回复，smelm。我在帖子中添加了更多背景信息。
您看过并行构建步骤吗？这比设置作业的内部版本号要容易得多（因为它应该只是正常递增）
此外，jenkins 管道（尤其是脚本化的）只是 groovy 脚本。 Jenkins 提供了一些功能，但它有一些限制（有利于可重启性），但最终它只是 groovy
再次感谢您，smelm。我们没有在我们的生产系统中使用管道。我收到的建议已经给了我一些思考的余地。我需要留出一些时间在我的测试 Jenkins 实例上进行一些尝试。我会回来报告的。

标签： jenkins

【解决方案1】：

取决于你是否使用Version Number plugin：

[ X ] Create a formatted version number
Build Display Name [ X ] Use the formatted version number for build display name.

假设你不是，这个groovy script 会做：

def NextNumber=42
job=Jenkins.instance.getItemByFullName('path/to/jobName')
job.nextBuildNumber = NextNumber
job.save();

为此，您需要groovy plugin。将其放在“执行 system Groovy 脚本”步骤中。确保选择 system groovy。这将在存储作业配置和元数据的主服务器上执行，因此您可以访问 Jenkins 内部和数据。

我建议您真的应该使用上述选项，而不是依靠通过脚本或手动“保持两个作业同步”。然后，您可以将第一个作业中要使用的标签作为参数传递给第二个作业。这也需要Parameterized Trigger 和Version Number 插件。

您甚至可以使用${BUILD_DATE_FORMATTED} 或${BUILD_TIMESTAMP} 等。

Postdate：从不同的角度考虑问题空间，即在不同平台上（同时）运行 2+ 个构建，有一个插件：Matrix project。您可以在多个节点上将其作为 freeatyle 作业运行，或者很好地描述为 Matrix building in scripted pipeline。不确定这将如何与 JIRA 联系起来。

【讨论】：

感谢您的评论。我没有使用版本号插件。我对从链接帖子中读到的 groovy 脚本感到相当满意。我很乐意尝试您建议的 groovy 代码 sn-p 但是我可以以某种方式将它作为构建步骤的一部分运行吗？也许我得单独研究一下。
感谢您更新的详细建议，伊恩。我们在生产系统中不使用管道，所以我将在测试实例上尝试一下。
添加了另一个选项。在您评估之前 +1 怎么样？
我需要为我的声誉而努力！由于我的“分数”低于 15，显然我的 +1 不公开。感谢您对此的兴趣和反馈。
优秀的答案，伊恩。非常感谢。正如您所建议的，我安装了 Groovy 插件并将 groovy 代码放在 JOB_A 的“执行系统 Groovy 脚本”步骤中：在此之前是执行 Windows 批处理命令步骤：echo %BUILD_NUMBER% > C:\Users\davidb\.jenkins \jobs\JOB_B\nextBuildNumber 然后我有一个构建其他项目的操作来运行 JOB_B。结果是，只要 Job_A 的内部版本号最初高于 JOB_B 的下一个内部版本号，JOB_A 就会在 JOB_B 之后运行，并且两个作业将具有相同的内部版本号。