代码之家  ›  专栏  ›  技术社区  ›  JDH

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

  •  0
  • JDH  · 技术社区  · 6 年前

    使用案例是我有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[]}
    

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

    enter image description here

    更新:为了进一步排除我如何使用令牌的问题,我在有问题的任务组中添加了第二个powershell任务。此脚本将访问AzDO restapi的另一个部分(如下所示)。这成功地得到了响应。所以OAuth令牌正在工作,它似乎无法访问整个API。

    $标题=@{ 授权=“持有人$env:SYSTEM_访问令牌" }

    $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}

    0 回复  |  直到 6 年前
        1
  •  0
  •   m00nbeam360.0    6 年前

    由于您使用的是System\u AccessToken变量,您是否也在代理作业中启用了“允许脚本访问OAuth令牌”复选框? https://docs.microsoft.com/en-us/azure/devops/pipelines/build/variables?view=azure-devops&tabs=classic#systemaccesstoken 这个链接显示了它在构建中的位置,但是您可以在发布版的代理作业面板的底部找到它。如果不检查,这可能就是为什么你得到一个空的响应。

    enter image description here

        2
  •  0
  •   Artem Alieinikov    5 年前

    完全一样的问题。我们考虑了两个选择,和你一直在尝试的一样。

    1. System.AccessToken
    2. 拍打

    这个问题通过把帕特放进一个钥匙库并用它作为基本密码来解决

    我的建议是,这似乎是意料之中的正确行为。我为什么这么认为?从azuredevops的角度来看,在我们的案例中,有两个级别:组织级别和项目级别。您可以注意到使用的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
    

    从安全性的角度来看,让较低层的实体(在我们的案例中是项目)访问和操作高层(在我们的案例中是组织)是一种糟糕的做法。

    专门为探员服务,另一个是个人资料。

    推荐文章