是否可以将TeamCity配置为在某些代理上运行个人构建？

我们有一个特殊的构建配置，需要它来运行大量的个人构建，而不会出现长时间的延迟。是否可以将特定代理专门用于运行个人构建？例如，如果我们有5个代理，是否有可能让所有5个代理都能够运行个人构建，但只有3个代理被VCS触发器解雇？我能看到的唯一方法是创建2个代理池。这种方法的问题是，您必须为每个池指定特定的项目，这将涉及复制构建配置

目前，个人构建在构建队列中配置了更高的优先级，但这无助于防止所有代理运行（缓慢）集成测试时出现延迟。理想情况下，这些集成测试将排队，直到能够运行它们的3个构建代理之一空闲为止。有许多变通方法可以帮助减少影响，最好知道是否可以将代理专门用于远程构建

---

截至2013年1月，我们正在运行TeamCity的最新版本，即7.1.3。

您可以通过指定代理要求来实现这一点。选择一个参数，将VCS自动触发的3个代理与其他2个代理区分开来。在每个构建配置中添加它作为代理要求，但要在所有5个代理上运行的配置除外。这样，您将把集成测试限制为3个代理，并释放其余2个代理，以便只运行需要大量个人构建的配置

---

此外，如果您使用构建配置模板，建议的代理池解决方案似乎也不太糟糕。

这并不能回答问题。这允许某些构建配置不在某些代理上运行，但与个人构建无关。这意味着使它工作的唯一方法是复制每个单独的构建配置，而这并不是真正的解决方案。我不想限制哪些生成配置可以在代理上运行。这是将生成配置限制到某些代理，这在代理->兼容配置选项卡中直接受支持。但是，相同的构建配置可以以许多不同的方式运行，包括作为个人构建。我们想将这些场景限制在某些代理上。您最初的问题是什么？您询问的是特定的解决方案，但最好了解您真正的问题。据我所知，您的代理数量有限（由于许可证？），并且您缓慢的集成测试正在阻止开发人员的个人构建，对吗？是的-问题正是您所描述的。由于代理执行长时间运行的配置，个人生成正在排队。在运行2015年4月的最新版本（v9.0.3）时，我们现在仍然存在相同的问题。那么，将您的问题颠倒过来，尝试在特定代理上运行缓慢的集成测试，并将其余的留给个人构建如何？如果您将集成测试限制在特定代理上，它将无法在任何其他代理上运行该配置的个人构建。我没有得到它。如果将集成测试限制在特定代理上，则可以在其他计算机上运行相同的配置生成。除非您将测试设置为一次只能运行一个实例。