Azure DevOps YAML 构建管道卡在自托管代理上答案

【问题标题】：Azure DevOps YAML build pipeline stuck on self-hosted agentAzure DevOps YAML 构建管道卡在自托管代理上
【发布时间】：2020-06-08 03:25:10
【问题描述】：

我在自托管代理上运行基于 YAML 的构建管道时遇到问题。触发构建后，它会卡在 Preparing an agent for the job - Waiting for the request to be queued。

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 中并行作业的最大数量的限制。

【问题讨论】：

我怀疑代理缺少运行作业的功能，请尝试调查
代理可以运行更复杂的构建，所以我觉得奇怪的是它缺少这样一个简单构建的能力。
好吧，您需要确定是什么阻碍了构建。通常是能力。这不是复杂与简单的问题。您的构建可能附加了任意capability
您是否检查过当前默认代理池中有多少个代理？如果池中既有旧代理也有新代理，我们无法确保它会为我们选择新版本代理来运行作业。（我曾经在使用一个相当老的代理 16.3 版本时遇到过类似的问题）。我认为您可以创建一个新代理池并在该池中注册一个新代理，然后在您的 yaml 中指定使用新代理池。结果如何？

标签： azure-devops yaml azure-pipelines azure-pipelines-yaml

【解决方案1】：

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

【讨论】：

【解决方案2】：

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

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

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

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

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

【讨论】：

【解决方案3】：

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

【讨论】：