时间戳

首页 > 解决方案 > Azure DevOps 在发布期间获取部署代理状态

azure-devops - Azure DevOps 在发布期间获取部署代理状态

问题描述

我正在尝试在发布时获取部署池中代理的状态。用例是我有 2 台带有共享磁盘的服务器，我希望该版本仅在一台服务器上运行。我有两个基于自定义条件运行的部署组：

eq(variables['DeployGroupSelector'], '1')

在确定 DeployGroupSelector var 值的作业之前运行的作业，本质上是一个 case 语句。

在设置 var 的工作中，我试图联系 Azure DevOps REST API：

$headers = @{
    Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN"
}

$url = "https://dev.azure.com/$($organization)/_apis/distributedtask/pools/$($poolId)/agents?api-version=5.1"
$response = Invoke-RestMethod $url -Headers $headers -Verbose
write-host "Output: $response"
$status = ($response.value | where {$_.name -eq $($env:primaryPoolName)}).status
if($status -eq "online")
{
    Write-Output("##vso[task.setvariable variable=DeployGroupSelector;]1")
}
else
{
    Write-Output("##vso[task.setvariable variable=DeployGroupSelector;]2")
}

对于包含上述脚本的组，选中“允许脚本访问 OAuth 令牌”框。

当我使用 PAT 在本地运行这个 powershell 时，它会返回数据。当我在 ADO 中运行发布时，它会访问服务，但返回一个空数据集：

2019-10-07T14:16:18.8942915Z VERBOSE: GET https://dev.azure.com/xxxxxx/_apis/distributedtask/pools/13/agents?api-version=5.1 with 0-byte payload
2019-10-07T14:16:19.3235204Z VERBOSE: received 22-byte response of content type application/json
2019-10-07T14:16:19.9626359Z VERBOSE: Content encoding: utf-8
2019-10-07T14:16:19.9835101Z Output: @{count=0; value=System.Object[]}

我尝试为“项目集合构建服务帐户”组提供对池和组的读取访问权限，我什至尝试将其提升给用户。我尝试添加构建服务帐户组以发布管理员。我什至尝试使用旧的 url 格式以防万一。

添加了从 powershell 返回的数据的图片：

在此处输入图像描述

更新：为了进一步排除我如何使用令牌的问题，我向相关任务组添加了第二个 powershell 任务。此脚本会命中 AzDO Rest API 的不同部分（如下）。这成功地得到了响应。所以 OAuth 令牌正在工作，它似乎无法访问整个 API。

$headers = @{ 授权 = "承载 $env:SYSTEM_ACCESSTOKEN" }

$url = "https://dev.azure.com/$($organization)/$($project)/_apis/git/repositories?api-version=5.1"
$response = Invoke-RestMethod $url -Headers $headers -Verbose
write-host "Output: $($response)"

回复：Output: @{value=System.Object[]; count=10}

标签： azure-devopsreleaseazure-devops-rest-api

解决方案

有完全相同的问题。分别考虑了两种选择，和你一直在尝试的一样。

  1. System.AccessToken
  2. 拍

通过将 PAT 放入 KeyVault 并将其用作管道中 REST API 调用的基本身份验证令牌，问题得以解决。

我的建议是，这似乎是预期的和正确的行为。为什么我会这么认为？从 Azure DevOps 的角度来看，在我们的案例中，组织级别和项目级别有两个级别。您可以通过使用的 URI 注意到不同之处：

$url = "https://dev.azure.com/$($organization)/_apis/distributedtask/pools/$($poolId)/agents?api-version=5.1"

$url = "https://dev.azure.com/$($organization)/$($project)/_apis/git/repositories?api-version=5.1

从安全的角度来看，让来自较低层的实体（在我们的案例中是项目）访问和操作较高层（在我们的案例中是组织）是一种不好的做法。

作为结论，我想说 SystemToken 和 PAT 在本质上略有不同，一个是专门用于代理的，另一个是用于个人资料的。

推荐阅读