Jenkins Pipeline“阶段内的节点”与“节点内的阶段”答案

【问题标题】：Jenkins Pipeline "node inside stage" vs "stage inside node"Jenkins Pipeline“阶段内的节点”与“节点内的阶段”
【发布时间】：2017-01-15 11:09:07
【问题描述】：

由于node step 和 stage step 都提供了作用域 {} 语法，在 groovy 代码中定义其拓扑的最佳实践是什么？

展览 A

node ("NodeName") {
    stage ("a stage inside node"){
        // do stuff here
    }
}

展览 B

stage ("a stage holding a node") {
    node ("NodeName"){
        // do stuff here
    }
}

【问题讨论】：

标签： jenkins groovy jenkins-pipeline

【解决方案1】：

这取决于你的实际需求。

只要您可以在单个节点上运行完整的管道，我会将 stages 包装在 node 中，这样管道就不会被繁忙的执行程序阻塞。

一旦您使用了parallel 步骤，那么除了在node 分配周围使用stage，您别无选择。

（至少对我而言）混合没有问题，即前 2-3 个阶段在同一个节点上执行，然后一个阶段在parallel 内的多个节点上执行。

【讨论】：

这很有趣。我在单个节点中有 5 个阶段。我需要将最后阶段放在不同的节点上（但不是并行的）。
那么你在哪里看到问题？
没问题...只是备注...我可能根本不需要“并行”步骤。
是的，从 1.2（2017 年 9 月）开始，可以有并行阶段：jenkins.io/blog/2017/09/25/declarative-1

【解决方案2】：

使用node { stage { ... } }，每个阶段都将共享同一个工作文件夹，并且上一阶段的所有文件都将在下一阶段使用。

使用stage { node { ... } }，您需要在每个阶段之间添加stash/unstash 文件。如果您有一个大型存储库，尤其是如果您有一个大型依赖项文件夹，例如 node_modules，那么重复的 stash/unstash 最终可能会成为重要的，甚至是大多数，或者您的构建时间。

IMO 我通常会从第一种语法开始，node { stage { ... } } 是首选。如果您有单独的构建阶段需要时间并且可以从并行性中受益，那么切换到 stage { node { ... } } 可能会更好，只要在并行化中获得的时间不会在存储中丢失。

更新：

我在我们的一个构建中测试了交换嵌套的确切效果。在一个节点内有一堆阶段，总构建时间刚刚超过一分钟。每个阶段内都有一个节点，总构建时间几乎是五分钟。大不同。

【讨论】：

好东西...感谢您分享您的发现。 stash / unstash 的问题在这里非常有帮助:)
这是一个很好的例子/解释。感谢分享。