我在自托管代理上运行基于 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 中并行作业最大数量的限制。
原来是代理池的权限问题。在
Organization Settings
=> Agent Pools
=> POOL_NAME
=> Security
中,有一个名为 Grant access permission to all pipelines
的设置。启用此功能后,我的构建现在可以按预期工作。
奇怪的是我还有其他现有的 YAML 构建管道 这在自托管代理上运行良好,但所有新管道 我试图创造,但最终却陷入了等待 请求排队。
您仅指定使用
Default
代理池。因此,它将在该池中选择一个可用的代理来运行该作业。
前往
Organization Settings
=> Agent Pools
查看 Default
代理池中可用的代理。
我们应该确保我们有一个可用的代理,其版本为2.164.8及更高版本,它应该是在线状态并且启用。然后我们可以暂时禁用该池中的其他代理,再次运行您的管道以检查它是否有帮助。 (在这种情况下,它应该选择好的代理来运行您的管道)
我想您可能在其他旧的 yaml 管道中对
pool:
有不同的定义。或者您可以创建一个名为 MyPool
的新代理池,并在 MyPool 中创建一个新代理,然后在 yaml 中指定使用 name: MyPool
来检查 Default
池中的代理是否有问题。
确保并检查代理是否在服务器上的 Windows 服务中运行。我遇到了看似相同的问题,但根本原因不同。 Azure Pipeline Agent... 服务在计划外中断后停止,导致服务无法重新启动。某人或某个进程已将服务启动属性设置为“自动启动(延迟)”而不是“自动启动”。
我也有类似的问题。当我检查我的自托管代理时,它显示为离线。
问题是我的 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
就我而言,我必须手动将代理更新到最新版本(从 2.xxx 到 3.xxx),并且由于某种原因,此更新未通过 CollectionSettings 中的 Azure DevOps 更新功能自动应用/代理池。