禁用并发构建

Question

背景：我们正在寻找有关如何优化我们的管道（以前的工作流程）的解决方案。

目前，我们运行了一些并行部署和测试，这些部署和测试分布在 2 个构建器上，每个构建器有 4 个执行器。

管道由 Git 推送触发，因此后续推送将触发多个构建。我们已经试验了阶段并发：1 选项，它很好地阻止了后续构建的一个步骤，但会在该特定阶段完成时启动。

问题：

我不确定这是最佳实践，但在我看来，最好不要执行新构建，直到前一个完成。（这是因为我们已经向它提交了资源，并且应该允许它完成，即使它不是最新和最大的提交）。

Q1：这是最好的做法吗？

Q2：我们如何抢占新的触发器构建，同时仍然运行前一个？（我可以想象遍历这项工作的构建并停止新工作......）。

见第一阶段的配置[1]

[1] 第一阶段..

stage name: 'Checkout and build WAR'
node {
    def mvnHome = tool 'Maven 3.2.x'
    checkout([$class                           : 'GitSCM',
          poll                             : true,
          branches                         : [[name: '*/master']],
          doGenerateSubmoduleConfigurations: false,
          extensions                       : [[$class           : 'RelativeTargetDirectory',
                                               relativeTargetDir: 'checkout-directory']],
          submoduleCfg                     : [],
          userRemoteConfigs                : [[url: 'https://some.repo/repo.git']]])

// Archive the cloned repo.
stash name: 'src', includes: 'checkout-directory/war/src/, checkout-directory/war/pom.xml'

// Run without tests, do the unit and integration tests in a separate stage.
sh "${mvnHome}/bin/mvn -f checkout-directory clean install -DskipTests"

// Archive the application build.
stash name: 'war', includes: 'checkout-directory/war/target/*.war'
}

Answer 1

来自工作的configuration您可以设置：

\n\n

\n
• 如有必要，执行并发构建
\n
• 安静期
\n

\n\n

\n

如果设置，新计划的构建会在实际构建之前等待这么多秒。这对于：

\n\n

\n
• 将多封 CVS 更改通知电子邮件合并为一封（当提交跨目录时，某些 CVS 更改日志电子邮件生成脚本会快速连续生成多封电子邮件）。
\n
• 如果您的编码风格是在几次 cvs/svn 操作中提交一个逻辑更改，那么设置较长的安静期将防止 Jenkins 过早构建并报告失败。
\n
• 节流构建。如果您的 Jenkins 安装因太多构建而过于繁忙，设置较长的安静期可以减少构建数量。
\n

\n\n

如果未在项目级别显式设置，则使用系统范围的默认值\n。

\n

\n\n

至于jenkins-pipelineDSL，这篇文章回答你的问题：

\n\n

\n

默认情况下，管道构建可以同时运行。stage 命令允许您将构建的某些部分标记为受到有限并发的约束（或者稍后不受约束）。当进入这样的限制阶段时，较新的版本总是被优先考虑；如果旧版本是 pre\xc3\xabmpted，则它们会提前退出。

\n

\n