Question

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

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

运行的作业要比确定DeployGroupSelector变量的值先运行的作业，本质上是一个case语句。

在设置变量的工作中，我正在尝试接触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}

Answer 1

由于您使用的是System_AccessToken变量，是否还启用了代理作业中的“允许脚本访问OAuth令牌”复选框？ https://docs.microsoft.com/en-us/azure/devops/pipelines/build/variables?view=azure-devops&tabs=classic#systemaccesstoken该链接显示了它在构建中的位置，但是您可以在发行版的“代理作业”面板的底部找到它。如果未选中，则可能是您收到空响应的原因。

Answer 2

有完全相同的问题。被认为是两个选项，与您尝试过的相同。

System.AccessToken
PAT

通过将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本质上有些许不同，一个用于代理，另一个用于个人档案。

Azure DevOps在发行期间获得Deployment Agent状态

2 个答案: