Azure DevOps YAML构建流程在自托管代理上卡住了。

Question

我在自托管的代理上运行基于 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 中并行作业的最大数量限制，确认没有受到此限制。请留意，HTML标记应该保留。

- sveinungf

---

我怀疑代理缺少运行作业的能力，请尝试调查一下。 - 4c74356b41

代理可以运行更复杂的构建，所以我觉得它缺乏这样一个简单构建的能力很奇怪。 - sveinungf

好的，你需要确定是什么阻碍了构建。通常是能力问题。这不是复杂与简单的问题。你的构建可能附带了任意的能力。 - 4c74356b41

你检查过当前默认代理池中有多少代理了吗？如果池中既有旧代理又有新代理，我们就不能确定它会选择新版本的代理来运行作业（我曾经使用一个相当老的16.3版本代理时遇到过类似的问题）。我认为你可以创建一个新的代理池并在其中注册一个新的代理，然后在你的yaml文件中指定使用新的代理池。结果如何？ - LoLance

Answer 1

事实证明是由于代理池的权限问题。在 组织设置 => 代理池 => POOL_NAME => 安全性 中，有一个名为 授予所有管道访问权限 的设置选项。启用此选项后，我的构建现在按预期工作。

- sveinungf

Answer 2

我遇到了类似的问题。当我检查自己托管的代理时，它显示为离线。

问题是我的Azure DevOps代理未运行。

以下是我如何解决的：

首先，我登录安装了代理的Linux服务器：

接下来，我导航到存储Azure DevOps代理安装文件的文件夹/目录：

cd <my-azure-devops-agent-directory>

当我列出文件时，下面显示的内容如下（您的内容可能略有不同）：

_diag
_work
bin  
config.sh  
env.sh  
externals  
kubectl  
license.html  
run-docker.sh  
run.sh  
runsvc.sh  
svc.sh

接下来，通过执行以下命令使用文件svc.sh将 azure-devops-agent 安装为服务：

sudo ./svc.sh install <your-user>

如果使用root用户安装：

sudo ./svc.sh install

接下来，通过运行以下命令使用文件svc.sh将azure-devops-agent作为服务启动：

sudo ./svc.sh start

通过运行以下命令，使用文件svc.sh检查azure-devops-agent作为服务的状态：

sudo ./svc.sh status

然而，如果你想以交互模式启动服务，则使用以下命令运行run.sh文件：

./run.sh

- Promise Preston

Answer 3

奇怪的是，我有其他现有的 YAML 构建流水线，在自托管代理上运行良好，但我尝试创建的所有新流水线都会被卡在“等待请求排队”的状态。

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

前往“组织设置”=>“代理池”以检查默认代理池中可用的代理。

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

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

- LoLance

Answer 4

请确保在服务器的Windows服务中检查代理是否正在运行。我遇到了看起来是相同问题，但根本原因不同的情况。Azure Pipeline代理服务在一次非计划停机后被停止了，导致该服务无法重新启动。某个人或某个进程已将服务启动属性设置为“自动启动（延迟）”，而不是“自动启动”。

- Bill Holman