TeamCity 中的快照依赖和完成构建触发器有啥区别？

Posted 2023-02-16

【中文标题】TeamCity 中的快照依赖和完成构建触发器有啥区别？

【英文标题】：What is the difference between snapshot dependency and finished build trigger in TeamCity?TeamCity 中的快照依赖和完成构建触发器有什么区别？

【发布时间】：2016-01-19 18:02:05

【问题描述】：

在我看来，快照依赖的功能完全取代了 TeamCity 中完成构建触发器的功能。如果它们导致不同的链行为，任何人都可以解释这些方法的效果吗？例如，如果我有一个 A->B

的构建链

这三种设置之间的链实际上有什么不同吗？

设置 1：B 中 A 的单个完成构建触发器。 设置 2：A 在 B 中的单个快照依赖关系。 设置 3：都完成了 A 的构建触发器和 B 中定义的 A 的快照依赖项。

我知道可以将快照依赖关系视为所有依赖项的“AND”操作，而 Finished Build Trigger 的工作方式类似于依赖项之间的“OR”操作。但是在顺序链的上下文中，有什么区别吗？

谢谢， 斯科特

【参考方案1】：

“快照依赖”和“完成构建”触发器非常不同。一个基本上是“推”操作，另一个是“拉”操作。

设置 1： 如果我有构建配置 A 和 B，其中 B 在 A 上有“已完成构建”触发器，那么相反的行为是正确的。触发B不会影响A，但触发A会在完成后有效触发B。

设置 2： 如果我有完全相同的设置，但 B 对 A 有快照依赖关系，那么每当触发 B 时，A 将首先运行，或者至少在运行 B 之前检查它是否需要运行。如果只触发A，则不会触发B。

设置 3： 设置 3 略有不同，因为它不仅仅依赖于“Finished Build”触发器或快照依赖项。它还取决于初始触发器（VCS、预定或其他）。例如，如果您在 A 上有一个 VCS 触发器，而 B 在 A 上有“已完成构建”触发器和“快照依赖项” ，那么您有效地获得了设置 1 的行为。A 将在 VCS 更改时触发，B 将在 A 之后触发（使用相同的快照）。事实上，如果没有快照设置，就不能保证 B 将使用与 A 相同的快照，这可能是也可能不是您想要的。

因此，一般来说，当您想要一个“从左到右”的触发过程时，您可以同时使用已完成的构建触发器和快照依赖项来保证构建附属物的神圣性。

另一方面，如果您在 B 上设置了初始触发器（VCS 或计划或其他），那么“完成构建”触发器在某种程度上无效，因为 B 总是会首先触发（但不运行），然后它会触发它的所有依赖项并在它们完成后自动运行。

希望对您有所帮助。谢谢！

【参考方案2】：

正如你所说，如果一个配置快照依赖于 多个 其他配置（Z 快照依赖于 X 和 Y），则会有很大的不同。但你对此不感兴趣......

确实可以说，在简单的 A->B 场景中，设置 1 .. 3 接近等效。当然，只有触发 A 和 B 的事件是一对一的（例如 A 和 B 都在同一个 VCS 根上触发；或者它们使用不同的 VCS 根但仅手动触发）。如果这是真的，那么您的 A->B 链非常简单，并且可以在单个构建配置中实现。

想到的其他细微差别：

向下传递参数。

假设 A 和 B 共享一些用户定义的参数“foo”。 A->B 快照依赖项允许您在 A 中定义 %foo% 并使用 %dep.A.foo% 在 B 中重用它。这真的很方便，因为您无需担心在 A 和 B 之间保持 %foo% 的值同步。 现在假设您要使用自定义值%foo% 手动触发 A->B 链（您将在“运行...”对话框中指定该值）。 由于 TC 无法将值 向上 传递到链中（从 B 到 A），因此您必须真正触发 A 并在那里指定自定义值。当 A 完成时，它会触发 B，它将超越自定义值。这就是设置 3。 您无法使用设置 2 实现相同的效果，即使用自定义值触发 B。自定义值无法传递给 A。

调度。

假设您拥有稀缺资源，而 B 不可能在每次提交时都运行。您最终会得到 B “包含”（覆盖）多个 VCS 提交的每次运行。同时，A 在每次提交时运行都没有问题。 在设置 1 和 3 中，如果 A 上有 VCS 触发器，您最终会得到 每次提交都运行 A 带有“聚合”提交的 B 运行（每次运行涵盖多个更改） 在设置 2 中，如果您仅在 B 上具有 VCS 触发器，那么您最终会在 A 和 B 中获得聚合提交。这可能是也可能不是您想要的...

不同的 VCS 根。

如果 A 和 B 具有不同的 VCS 根，则设置 1（仅在 A 上使用 VCS 触发器）和设置 2（仅在 B 上使用 VCS 触发器）的行为将完全不同。

总的来说，我同意快照依赖项（设置 2）的“拉动”性质更具吸引力。如果需要，与触发器结合使用（设置 3）。

【讨论】：

感谢您的详细解释。在我的情况下，共享参数和稀缺资源非常罕见，因此我可能会默认仅使用快照依赖项（设置 2），如果需要不同 VCS 根的特定行为，则使用组合（设置 3）。

您能否在设置 3 中澄清一下，如果 snapshop 依赖项具有“如果有合适的版本，则不运行新版本”UNCHECKED 选项，A 是否会运行两次？如...某事触发 A，当 A 完成时，Finished Build 启动并尝试将 B 放入队列，然后 Snapshot Dependency 启动并再次将 A 放入队列在 B 排队之前。当我测试此设置时，它不会在队列中放置另一个 A，但我认为理论上应该。如果完成构建触发器存在，TeamCity 是否有内部逻辑来忽略快照依赖项的排队步骤？

即使未选中此选项，我认为 A 也不应该重新排队。那将是非常不切实际的，我想不出任何人可能会渴望这种行为。 （我想你也不想要那种行为，你只是想知道如果不是 that，这个选项会做什么。）我相信这个选项的作用是：踢 A，让 B 触发.两者都跑过一次。现在仅手动触发 B，自上次 B 构建以来没有任何代码更改。那是否应该再次触发A？这就是这个选项发挥作用的地方。

是的，我只是想了解这个选项。我不想要这种行为，所以我知道我可以安全地使用设置 3，并且不会导致重新排队——即使 teamcity 自己的描述并不清楚这部分。谢谢你的帮助。抱歉，我无法投票。