Testing TeamCity快照依赖项而不触发重建

TLDR：如何安排快照依赖项，使其不会触发新生成？

为了让我的测试进程运行，它们需要在“测试”环境中运行。创造这样一个环境很简单，但很漫长；完成测试环境的构建可能需要45分钟到一个小时。此外，在环境完成构建之前，环境的名称和其他此类变量不会固定

在我的TeamCity构建定义中，我可以将“缺少构建环境”作为构建步骤。然而，这意味着当天的第一次测试需要45分钟才能运行

相反，我们创建了一个单独的构建，计划每天早上运行，用于构建当天的测试环境。然后，我们的测试构建对该构建有一个快照依赖关系，以便使用该构建的参数来确定环境信息，除一个问题外，所有工作都按预期进行：

当运行一个新测试时，它经常会触发测试环境创建的重建。

我们不希望这种情况发生；当天的测试环境创建已“完成”，在明天之前不需要再次运行。我们如何才能做到这一点

您已经有了基于时间的触发器=>每天早上都会准备好环境

在产品TC配置中创建快照依赖项（不在准备测试环境的配置中），并勾选“如果有合适的快照依赖项，请不要运行新版本”

用于设置测试环境的配置不应具有任何VCS根目录（或指向不会发生提交的源代码管理的某个平静位置）。要物理设置您的环境，您不需要任何源代码映射等-例如，您可以通过自己的NuGet包使用所需的一切

注意：在这个工作流中，实际项目的每个构建都将登记设置测试环境的配置构建（因此它实际上在构建队列中）但是

---

当它出现时，它将比较自上次生成以来的更改=>未在VCS上找到提交（它指向SourceControl中的“平静之地”（由于步骤3）），因此将在中跳过生成。是否需要快照依赖关系？唯一的原因是触发依赖性构建，但这正是您试图避免的。我们有一些相同的问题，设置“如果有合适的构建，则不运行新构建”似乎并不总是奏效。我们经常看到由后续构建触发的“无更改”列表中的重建。真的经常吗？这些重建可能由TC预测可能影响生成输出的事件触发（例如TC配置中的更改），设置“test env”的TC配置也不应具有任何工件/快照依赖关系。对于我们来说，在5个依赖层上组装80个TC项目是正常的，没有这样的问题（9.1.4 build 37293）。您所描述的内容似乎是TC中的错误（值得提交的错误报告）或您的工作流程中的问题。在生成被触发而它们不应该被触发的情况下，您看到了什么有趣的事情吗？