Question

我在自托管代理上运行基于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中并行作业的最大数量的限制。

Answer 1

奇怪的是，我还有其他现有的YAML构建管道在自托管代理上正常运行，但是所有新管道我试图创建只是最终陷入了等待请求排队。

您仅指定使用Default代理程序池。因此它将在该池中选择一个可用的代理来运行该作业。

转到Organization Settings => Agent Pools来检查Default代理程序池中的可用代理程序。

我们应确保我们有一个具有 2.164.8及更高版本的可用代理，该代理应处于在线状态并启用。然后，我们可以暂时禁用该池中的其他代理，再次运行管道以检查是否有帮助。（在这种情况下，它应该选择好的代理来运行您的管道）

我想也许您在其他旧的Yaml管道中对pool:有不同的定义。或者，您可以创建一个名为MyPool的新代理池，并在MyPool中创建一个新代理，然后在yaml中指定使用name: MyPool来检查Default中的代理是否存在问题池。

Answer 2

事实证明是代理池的权限问题。在Organization Settings => Agent Pools => POOL_NAME => Security中，有一个名为Grant access permission to all pipelines的设置。启用此功能后，我的构建现在可以按预期工作。

Answer 3

确保并检查代理是否在服务器上的 Windows 服务中运行。我遇到了看似相同的问题，但有不同的根本原因。 Azure Pipeline Agent... 服务在计划外中断后停止，导致服务未重新启动。某人或某个进程已将服务启动属性设置为“自动启动（延迟）”而不是“自动启动”。

Azure DevOps YAML生成管道卡在自托管代理上

3 个答案: