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

Question

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

的构建链

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

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

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

谢谢， 斯科特

Answer 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 总是会首先触发（但不运行），然后它会触发它的所有依赖项并在它们完成后自动运行。

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

Answer 2

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

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

想到的其他细微差别：

1. 向下传递参数。

   • 假设 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。

2. 调度。

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

3. 不同的 VCS 根。

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

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