我在自托管代理上运行基于YAML的构建管道时遇到问题。触发构建后，它会卡在为工作准备代理-等待请求排队。
azure-pipelines.yml看起来像这样：
trigger:
- master
pool:
name: Default
steps:
- script: echo Hello, world!
displayName: 'Run a one-line script'
如果我更改为Microsoft托管代理，则该构建确实起作用：
trigger:
- master
pool:
vmImage: ubuntu-16.04
steps:
- script: echo Hello, world!
displayName: 'Run a one-line script'
奇怪的是，我还有其他现有的YAML构建管道在自托管代理上运行良好，但是我尝试创建的所有新管道最终都陷入了等待请求排队的状态。
我已经尝试了当前最新版本的代理守护程序，即2.164.8和2.165.0，都无济于事。我还检查了我是否不受DevOps中并行作业的最大数量的限制。
答案 0 :(得分：1)
奇怪的是，我还有其他现有的YAML构建管道 在自托管代理上正常运行，但是所有新管道 我试图创建只是最终陷入了等待 请求排队。
您仅指定使用Default代理程序池。因此它将在该池中选择一个可用的代理来运行该作业。
转到Organization Settings => Agent Pools来检查Default代理程序池中的可用代理程序。
我们应确保我们有一个具有 2.164.8及更高版本的可用代理，该代理应处于在线状态并启用。然后，我们可以暂时禁用该池中的其他代理，再次运行管道以检查是否有帮助。 （在这种情况下，它应该选择好的代理来运行您的管道）
我想也许您在其他旧的Yaml管道中对pool:有不同的定义。或者，您可以创建一个名为MyPool的新代理池，并在MyPool中创建一个新代理，然后在yaml中指定使用name: MyPool来检查Default中的代理是否存在问题池。
答案 1 :(得分：0)
事实证明是代理池的权限问题。在Organization Settings => Agent Pools => POOL_NAME => Security中，有一个名为Grant access permission to all pipelines的设置。启用此功能后，我的构建现在可以按预期工作。
答案 2 :(得分：0)
确保并检查代理是否在服务器上的 Windows 服务中运行。我遇到了看似相同的问题，但有不同的根本原因。 Azure Pipeline Agent... 服务在计划外中断后停止，导致服务未重新启动。某人或某个进程已将服务启动属性设置为“自动启动（延迟）”而不是“自动启动”。