防止Teamcity上不必要的触发器

我在问题和答案上都搜索了我的问题。我可以找到一个与我的问题相同的问题，但遗憾的是，它没有得到回答

我有很多模块，同样的情况下也有很多依赖项

简化

我有X、Y、Z模块和类似的依赖项：Z->Y->X

当代码提交到X模块时，X1开始运行

X1完成时，Y模块触发，Y1开始运行

Y1完成后，Z模块触发，Z1开始运行

Z1运行时，提交给Y和Y2的代码开始运行

此时，由于Z2将在Y2完成后立即触发，因此Z1构建将变得不必要。因为Z2较新，必须使用Z2

另一方面，依赖于Z的模块也将被不必要地触发（当Z1完成时），因为Z2将在Z2完成时触发相同的模块

我查看了Teamcity的文档；还有论坛。我不认为这是罕见的情况，但无法找到答案或解决办法

---

任何帮助都将不胜感激。

我理解这种痛苦，但我认为这种工作方式对于正确地将问题构建映射到提示它们的代码更改是必要的。例如，如果Z1成功完成并进行了5次更改，但Z2失败并进行了3次更改，则您不一定希望Z1中的代码与失败的构建相关联

如果构建花费了足够长的时间或花费了您不愿意花费的计算资源，您可以考虑取消Z1构建，我不知道有什么内置机制可以做到这一点，但您可以编写自己的插件，或者通过构建步骤编写脚本

TeamCity中的RESTAPI提供了一些处理方法，您可以看到更多

如果您在teamcity中设置了依赖项，则会设置静默期。例如，如果您签入某个内容并有5分钟的静默期，teamcity将在开始构建之前等待5分钟。如果您的提交是在短时间内发生的，则可以使用slient period选项。然而，如果您的团队经常提交，这并不能解决您的问题

如果项目中的提交频繁，还可以在依赖项中使用“适当的构建”选项。我建议你仔细阅读一下，看看是否适合你的要求

你的构建速度快吗？在这种情况下，我实际上不介意在运行X2->Y2->Z2之前看到X1-Y1-Z1完成。原因是，如果运行快照依赖项，则更容易确定Z1中的提交是破坏了构建还是Z2中的提交。如果您将Z1和Z2作为同一个构建的一部分运行，那么要找出哪个提交开始导致构建问题将变得更加困难和耗时

编辑

通常情况下，X1->Z1存在此问题。在我们的例子中，X1运行得非常快，而Z1需要很多时间。teamcity在这种情况下所做的是，如果存在X2，它就不会运行Z1。它直接从Z2开始。我们使用快照依赖项和构建链来实现它

有两个问题要问你

你所有的构建都是超快速的还是需要时间的

您的所有构建是否都来自不同的回购/子回购，或者它们是否运行完全相同的回购

您可以做的一个简单的黑客操作是在build X中为所有构建提供一个版本号，将其写入文件或teamcity属性，并通过X1-Y1-Z1传播它们（您可以使用依赖构建的参数传播它们）。对于Y和Z中的每个构建，您可以检查X是否已移动到更高版本

考虑这个场景， 1.如果X1构建为v1.1，Y1完成，现在Z1开始运行。 2.同时X2已经运行完毕，新版本为1.2 3.在目标Z2中，您可以检查新版本是否为1.2，并且由于您在v1.1上运行，因此可以跳过运行（我将根据您的需求让您决定是跳过还是出错）

---

如果您可以选择在每次提交时构建X1，那么您甚至可以在Y1 target

Hi Mark中这样做。问题不在于失败的构建。当一个生成配置触发多次（一个由直接依赖项触发，第二个由依赖项的依赖项触发）时，第一个生成将过时，并且该生成也会触发生成。我知道您遇到的问题与失败的生成无关，我的意思是team city这样做的方式是支持失败的构建。我用一种可以用来取消buildHi Biswajit的方法更新了我的答案。正如你所说，沉默期解决不了我们的问题。我研究了合适的构建概念，但似乎解决不了太多问题。假设没有损坏的构建。我试图为那些花费在不必要构建上的代理节省时间（在我的问题中，是z1和由z1触发的构建）。我们可以看出z1和由z1触发的构建可以手动取消，对吗？在这一点上，我试图找出teamcity是否能够实现并取消这一构建。