将管道的一部分作为单独的作业运行

我们正在考虑将 Jenkins Pipeline 插件用于一个相当复杂的项目，该项目由多个交付组成，在合并之前需要使用不同的工具（在不同的机器上）构建这些交付。尽管如此，使用单个程序完成完整的构建似乎很容易Jenkinsfile，而且我喜欢 Pipeline 附带的自动发现 git 分支的功能。

然而，此时，我们为每个交付都有作业，并使用基于构建流的“元”作业来编排各个作业。这样做的好处是，如果只进行了很小的更改，它还允许只启动一项单独的工作，只是为了看看这个交付是否仍然可以编译。

为了模仿这一点，我想到了一些想法：

• 使用不同的Jenkinsfiles 用于交货和load他们在顶层Jenkinsfile;看来多分支管道作业不允许配置Jenkinsfile尚未使用（https://issues.jenkins-ci.org/browse/JENKINS-35415），但是，为个人交付创造就业机会仍然是开放的。
• 为“顶级”作业提供配置选项并具有ifs 对于所有交付Jenkinsfile能够选择应该构建哪个。不过，这会在一个管道中混合不同的构建类型，并且至少会扰乱构建时间的估计。

这些是可行的选择，还是有更好的选择？

您可以做的是编写一个在单个阶段周围有“of”守卫的管道脚本，如下所示：

stage "s1"
if (theStage in ["s1","all"]) {
    sleep 2
}

stage "s2"
if (theStage in ["s2", "all"]) {
    sleep 2
}

stage "s3"
if (theStage in ["s3", "all"]) {
    sleep 2
}

然后，您可以创建一个使用此脚本的“主”作业，并通过将参数“theStage”设置为“all”来一次运行所有阶段。该作业将在所有阶段同时运行时收集统计数据，并为您提供有用的估计时间。

此外，您可以创建一个使用此脚本的“部分运行”作业，并使用您想要运行的阶段进行参数化。不过，这个估计不会很有用。

请注意，我将阶段本身放入主脚本中，并仅将执行代码放入条件中，正如 Martin Ba 所建议的那样。这确保了工作的可视化更加可靠