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 构建管道，它们在自托管代理上运行良好，但我尝试创建的所有新管道最终都卡在了Waiting for the request to be queued 。

我尝试了当前最新版本的代理守护进程，包括 2.164.8 和 2.165.0，但无济于事。 我还检查了我不受 DevOps 中并行作业的最大数量的限制。

Answer 1

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

Answer 2

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

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

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

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

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

Answer 3

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

Answer 4

我有一个类似的问题。 当我检查我的自托管代理时，它显示为Offline 。

问题是我的 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