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

Question

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

链条在这三种设置之间的实际行为有何不同？

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

据我所知，可以将Snapshot Dependency视为所有dependees的“AND”操作，而Finished Build Trigger在dependees之间的操作类似于“OR”。但在顺序链的背景下，有什么区别吗？

谢谢， 斯科特

Answer 1

“Snapshot Dependency”和“Finished Build”触发器非常不同。一个基本上是“推”操作，而另一个是“拉”操作。

设置1： 如果我构建了配置 A 和 B ，其中 B 在 A 上有“完成构建”触发器，那么相反的行为是真的。触发 B 对 A 没有影响，但触发 A 会在完成后有效触发 B 。< / p>

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

设置3： 设置3略有不同，因为它不依赖于“完成构建”触发器或快照依赖性。它还取决于初始触发器（VCS，预定或其他）。例如，如果您在 A 上有VCS触发器，而 B 在 A 上同时具有“完成构建”触发器和“快照依赖项” ，然后你有效地获得了安装程序1的行为。 A 将在VCS更改时触发， B 将在 A 之后触发（使用相同的功能）快照）。实际上，如果没有快照设置，则无法保证 B 将使用与 A 相同的快照，这可能是您想要的，也可能不是。

所以一般来说，当你想要一个“从左到右”的触发过程时，你可以使用BOTH完成的构建触发器和快照依赖来保证构建抵押品的神圣性。

另一方面，如果您在 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无法传递 up 链（从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）。