我在使用 Jenkins 构建管道时遇到问题。第一个作业之后的所有作业都使用第一个作业的“运行参数”进行参数化。默认情况下，这应该引用第一个作业的最新稳定版本。每个后续作业都使用第一个作业的“运行参数”来访问第一个作业中保存的工件。每个后续作业都会作为参数化构建触发管道的下一个作业，并传递上述“运行参数”。管道的第一个作业作为简单（即未参数化）构建触发第二个作业。
下面是一个下游作业的相关配置截图：
我的问题是“运行参数”中的作业号不是管道第一个作业的作业号。相反，它是 previous 管道的第一个作业的作业编号。因此，如果第一个作业在 build #11 上，那么该管道的所有后续作业都将访问第一个作业的 build #10 的存档。
如何让管道的后续作业访问管道第一个作业的存档目录？
【问题讨论】：
标签： jenkins continuous-integration
我发现了答案。显然，下游作业使用 previous 管道上游作业的工件的原因是因为我在下游作业的配置中将“运行参数”过滤器设置为“仅稳定构建” .将此过滤器设置为“所有构建”会导致正确的行为。
当 Jenkins 在其后期构建部分开始另一个构建时，就好像 Jenkins 不认为上游作业是稳定的。
【讨论】：
引用：“默认情况下，这应该引用第一个作业的最新稳定版本。”
您是指 Top 作业的最后一次成功构建。因为在这种情况下，可能会出现上一次成功构建顶级作业是 #7 而当前构建是 #11 的情况。因此，您希望下游作业寻找 #7 而不是 #10。
如果是这种情况，那么我会建议放置一个 groovy 构建步骤。为此安装 groovy 插件。但在此之前测试脚本。
打开：YourJenkinsServerURL/脚本
运行此脚本。
def tmp = hudson.model.Hudson.instance
def myJobName="YourTopJobName";
tmp.getItems(hudson.model.Job).each {job ->
if(job.displayName == myJobName)
{
println(job.getLastSuccessfulBuild())
}
}
在 groovy 中，您可以访问并设置一个环境变量（可能通过 envInject 插件注入）到最后一个成功的内部版本号，然后将此变量传递给下游作业。
如果不是这样，那么我会建议使用 Nant 脚本。 使用“int::parse()”将字符串格式的内部版本号转换为整数。递减该值，然后将该值传递给下游作业。
【讨论】：