Jenkins 下游流水线作业未按预期触发

问题描述

在Jenkins上设置了三个独立的多分支流水线作业，并希望按顺序调用它们作为下游作业。请注意，这3个作业都有独立的git仓库！每个作业都有自己的Jenkinsfile。第一个作业总是由用户通过Jenkins UI手动触发。在第一个作业的Jenkinsfile的最后一个阶段，会触发第二个作业，如下所示。（第二个作业以相同的方式触发第三个作业）

stage('Trigger second job'){
   steps {
       build job: 'second_job_name', propagate: true, wait: false
   }
}

现在，当第一个作业结束时，这个步骤似乎总是成功执行，日志中没有出现错误或警告。这应该意味着第二个下游作业已经被调用，但不幸的是，并不总是这样：
– 有时第一个作业触发了第二个作业，但第二个作业实际上从未触发第三个作业，尽管它似乎通过了相应的Jenkinsfile阶段。
– 有时第一个作业完成后根本不触发第二个作业。

只有当这3个git仓库都有新的提交时，这个设置才能按预期工作。然后，所有3个作业都会按顺序触发，没有问题。

有人知道这种不一致行为的原因吗？也许是因为这些作业基于不同的git仓库？我能做些什么来解决这个问题吗？

解决方案

请注意以下操作注意版本差异及修改前做好备份。

方案1

我怀疑问题出在作业名称上：

build job: 'second_job_name'

在多分支流水线中，作业名称通常包含文件夹。例如，如果你有一个名为”my_project”的多分支项目，该项目中有一个名为”my_repo”的仓库，并且你希望构建该仓库中的一个分支，比如”master”，那么你的构建命令应该是：

build job: 'my_project/my_repo/master'

如果你只在作业名称中指定了项目或仓库级别，而没有包含分支，那么Jenkins将扫描该项目/仓库中的所有分支的更新，并构建尚未构建的任何新提交。这就导致了你描述的症状：

只有当这个设置中的所有3个git仓库都有新的提交时，才能按顺序触发所有3个作业，没有问题。

方案2

如果方案1无效，你可以尝试使用其他方法来控制作业的触发顺序。
另一种方法是使用Jenkins的插件或其他工具来控制作业的触发顺序。你可以使用build命令手动控制作业的触发顺序，或者使用一些第三方工具来管理作业之间的依赖关系。

希望这些解决方案能帮助你解决问题！如果有任何其他问题，请随时提问。