我正在测试TFS 2013到TFS 2018 onprem升级。我在新系统上安装了2018.1(并升级了我的TFS数据库的副本)。我已在新主机上安装了构建代理,该代理显示在代理队列下(在线并启用)。
我现在正在尝试创建一个版本。我按照自己的意愿设置了它,并且它位于这个屏幕上:
Build
Waiting for an available agent
Console
Waiting for an agent to be requested
VSTS代理服务正在构建代理系统上运行。所以我觉得没关系。我有些不知所措。任何帮助表示赞赏。
答案 0 :(得分:2)
只需尝试以下项目即可缩小问题范围:
检查服务" Visual Studio Team Foundation后台作业代理" 是否在TFS应用层服务器上运行。
如果没有启动,只需启动该服务。
如果状态为正在运行,只需尝试重新启动该服务。
答案 1 :(得分:1)
TF后台作业代理未在应用程序层上运行,因为该帐户没有“作为服务登录”。
答案 2 :(得分:0)
我们仅花了五天的时间来诊断此问题,并相信我们终于确定了原因(以及解决方案!)。
TL; DR版本:
我们正在使用TFS 2017 Update 3 YMMV。我们认为问题是由于代码搜索扩展使用的弹性搜索组件的旧版本配置错误导致的。如果您不使用代码搜索功能,请禁用或卸载此扩展程序并报告-我们已经看到了巨大的改进。
详细说明:
因此,我们发现MS重新调整了弹性搜索组件的用途以在TFS中提供代码搜索功能-如果您选择包括搜索功能,则在安装TFS时将安装该服务。
对于那些不熟悉Elastic的人来说,一个特别重要的方面是它使用了多节点架构,可以在节点之间转移负载并在整个群集之间平衡工作量,这就是MS代码搜索的问题。
(严重地)将TFS中安装的Elastic Search组件配置为单节点,并故意抑制或禁用了多种功能。将高水位标记设置设置为85%后,一旦搜索数据达到数据驱动器上可用磁盘空间的85%,该节点就会停止创建新索引,并将仅接受现有索引中的数据。
在普通的Elastic集群中,这将导致另一个节点创建一个新索引来接受新数据,但是由于MS将集群划分为一个节点,因此回退...是同一节点-冲洗并重复。
通过查看构建代理程序与构建控制器之间的通信,我们看到的行为表明构建控制器尝试与Elastic进行通信并最终失败。随着时间的流逝,Elastic变得越来越无响应,并阻塞了这种通信,这表现为控制器花费越来越长的时间来响应构建请求。
仅由于我们实际使用了Elastic Search,我们才能够解释行为并记录得出该结论。没有这些知识,几乎不可能确定实际原因。
如何解决此问题?
有多种方法可以解决此问题:
如果您不想使用代码搜索功能,请不要安装它。该问题不会发生。
如果您不使用代码搜索功能,请将其卸载。问题将消失-您可以仅禁用所有集合中的扩展名,也可以使用服务器安装程序将其完全删除。我有MS的详细说明,供所有想完全消除它的人参考,
如果正确使用Elastic,而不是将其单独塞入一个小盒子中,则不会发生此问题。
Elastic将继续“正常”运行,并应在有限的参数范围内按预期返回搜索结果。
希望这可以帮助某人避免我们遭受的痛苦。
答案 3 :(得分:0)
我遇到了同样的问题,就我而言,它是通过重新启动TFS服务器(TFS在我们办公室本地托管)解决的。