Azure Pipelines 中的单个 CI 与批量 CI

Question

Azure Pipelines 中的单个 CI 和批量 CI 有什么区别？

batch它与 Azure Pipelines YAML 中的选项有何关系trigger？

trigger:
  batch: 'true'
  branches:
    include:
     - main

Answer 1

\n
它与 Azure Pipelines YAML 中触发器的批处理选项有何关系？
\n

\n

正如文档Push 触发器所述：

\n

trigger:\n  batch: boolean # batch changes if true; start a new build for every push if false (default)\n

解释：

\n

构建批处理将进行多次推送（分支更新）并在一批中一次性构建它们，而不是将每个提交作为单独的构建进行排队，这会延长构建的总时间。如果您在 Azure Pipelines 中构建代码并且经常发现自己在等待排队构建。您可能会发现启用构建批处理很有用。

\n

所以，我们现在可以理解该文件中的状态了start a new build for every push if false (default)。这意味着如果我们将此批处理选项的值设置为 false，它将为每次推送（提交）启动一个新的构建。

\n

这相当于经典模式下的“构建正在进行时批量更改”选项\xef\xbc\x9a

\n

发现[这个解释](https://cloudskills.io/blog/ci-dotnet-core#:~:text=Batch%20changes%20while%20a%20build,as%20a%20separate%20pipeline%20run.)也很有用：“在构建过程中进行批量更改 - 如果您在一个大型团队中工作，那里有频繁的推送和/或 PR 完成推送，您最终可能会在构建仍在进行时对多个构建进行排队。此复选框将停止每个构建这些推送作为单独的管道运行排队。当前构建完成后，它将对所有更改的一次运行进行排队。” (5认同)
我认为在这个答案中使用“提交”这个词可能会让一些人感到困惑。想象一下这样的场景：50 个新提交一次合并到一个分支中。这将触发 1 次构建，而不是 50 次构建。（这对大多数人来说可能是显而易见的，但我建议删除两次出现的“提交”一词，以避免任何潜在的混淆。）我认为“推送”或“分支更新”在这里效果很好。 (4认同)