Get best of the week

在Azure DevOps管道中使用变量

我们将继续审视用于Windows的出色开发工具，不仅限于Azure DevOps。这次，在环境变量的折磨下，我决定将所有经验写在一篇文章中。

从事实出发，对于每个运行时环境，它们都有不同的语法，最后是缺乏将变量从管道的一个阶段转移到另一阶段的标准能力。

我会保留主要的示例，这些示例将在Release Pipelines上发布，因为YAML尚未实现，而且我需要许多阶段和许多工件的功能。看来，这可以在常规管道中使用，实际上可以使它们的功能达到平衡。在管道中，YAML在文本视图中添加了带有可设置参数的小型图形工具提示，并在文本视图中添加了该工具提示。非常方便，无需进入每个模块的文档。但是我将在下一篇文章中对此进行描述，但是现在，这是创新本身的图片。



储存与使用


首先，我们在系统中有默认变量。根据来源，它们以单词Release，System等开头。文档中提供了完整列表（事实证明是，否）。以下文档中的示例说明了所有带有语法的精神分裂症。同一变量具有三种表示形式，具体取决于我们在何处调用它。

steps:
 - bash: echo This script could use $SYSTEM_ACCESSTOKEN
    env:
      SYSTEM_ACCESSTOKEN: $(System.AccessToken)
  - powershell: Write-Host "This is a script that could use $env:SYSTEM_ACCESSTOKEN"
    env:
      SYSTEM_ACCESSTOKEN: $(System.AccessToken)

如果在正在执行任务的代理上设置变量，则该变量为$（System.AccessToken）。如果要在同一代理上的Powershell脚本中使用它，它将已经是$ env：SYSTEM_ACCESSTOKEN。上帝禁止，如果您想使用目标机器上的PowerShell任务在某个远程主机上使用此变量，则需要使用param将其通过参数传递给脚本。使用bash更加简单，您只需使用参数和语法$ SYSTEM_ACCESSTOKEN即可将其放入。

相同的定律不适用于您自己的变量，此处您已经负责语法。您可以在每个任务中本地设置变量。



或全局存储在变量中，然后从存储链接它们。非常舒适。



另外，如果变量非常秘密，则可以将变量存储在Azure云中称为Azure Vault的存储中，可以将Vault链接到库中的项目。



通常，变量是很清楚的，在管道中，您仍然可以为每次启动手动设置它们，而在发行版中则没有这种功能。您可以在代理初始化日志中再次看到转移到管道的内容，但是请注意，它们已经以转换后的形式存在。



动态变量


当我们想要在一个阶段中获得一些价值并将其传递到下一个阶段时，最有趣的部分开始。



此类功能尚未交付给我们。但是我们的双手并非无聊，在Google的帮助下找到了解决方案。谢谢上帝，Azure DevOps有一个API，它使我们可以做的比我们在界面中绘制的要多。

因此，我们需要一个调用来更新全局变量，这将在管道内部进行。地址是从环境变量中获取的，如前所述，该变量在文档中一字不漏。您可以问他们自己，或者问他们关门时有什么硬编码。

$releaseurl = ('{0}{1}/_apis/release/releases/{2}?api-version=5.0' -f $($env:SYSTEM_TEAMFOUNDATIONSERVERURI), $($env:SYSTEM_TEAMPROJECTID), $($env:RELEASE_RELEASEID)  )

设置我们要传递的变量的空值，设置范围-发布，



例如，我们随机生成一些值。在此阶段要注意变量声明的语法，引入了此类功能。



在下一步中，我们将变量传递给脚本，是的，直接不可能，需要通过参数来实现。



剧透下的剧本

Powerhell
#Script requires stageVar variable in release variables set to Release scope

param ( [string] $expVar )
#region variables
$ReleaseVariableName = 'StageVar'
$releaseurl = ('{0}{1}/_apis/release/releases/{2}?api-version=5.0' -f $($env:SYSTEM_TEAMFOUNDATIONSERVERURI), $($env:SYSTEM_TEAMPROJECTID), $($env:RELEASE_RELEASEID)  )
#endregion


#region Get Release Definition
Write-Host "URL: $releaseurl"
$Release = Invoke-RestMethod -Uri $releaseurl -Headers @{
    Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN"
}
#endregion

#region Output current Release Pipeline
Write-Output ('Release Pipeline variables output: {0}' -f $($Release.variables | ConvertTo-Json -Depth 10))
#endregion


#region Update StageVar with new value
$release.variables.($ReleaseVariableName).value = "$expVar"
#endregion

#region update release pipeline
Write-Output ('Updating Release Definition')
$json = @($release) | ConvertTo-Json -Depth 99
Invoke-RestMethod -Uri $releaseurl -Method Put -Body $json -ContentType "application/json" -Headers @{Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN" }
#endregion

#region Get updated Release Definition
Write-Output ('Get updated Release Definition')
Write-Host "URL: $releaseurl"
$Release = Invoke-RestMethod -Uri $releaseurl -Headers @{
    Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN"
}
#endregion

#region Output Updated Release Pipeline
Write-Output ('Updated Release Pipeline variables output: {0}' -f $($Release.variables | ConvertTo-Json -Depth 10))
#endregion


要么

重击
INPUT_VAR=$1
RELEASE_VAR=$2

echo Test ID: ${INPUT_VAR}

RELEASE_URL="${SYSTEM_TEAMFOUNDATIONSERVERURI}${SYSTEM_TEAMPROJECTID}/_apis/release/releases/${RELEASE_RELEASEID}?api-version=5.0"

echo release url: $RELEASE_URL

RELEASE_JSON=$(curl -H "Authorization: Bearer $SYSTEM_ACCESSTOKEN" $RELEASE_URL)

OUTPUT=`jq ''.variables.${RELEASE_VAR}.value' = '\"${INPUT_VAR}\"'' <<< $RELEASE_JSON`

curl -H "Authorization: Bearer $SYSTEM_ACCESSTOKEN" -H "Content-Type: application/json" -X PUT -d "$OUTPUT" $RELEASE_URL


简而言之，我们的脚本采用了输入变量myVar，并且使用API​​将该变量的值放入stageVar。在下一步中，我们将使用系统变量的语法进行查看。



该示例非常简单，但是在上一篇文章中，该功能为我们提供了很好的机会，我们可以在测试的第一阶段创建虚拟机，对其进行一些进一步的操作，同时进行多次操作。最后一步是销毁它。现在，我们每次都在新的虚拟机上进行产品自测。考虑到他们活了10分钟，值得一分钱。

在下一篇文章中，如有必要，我将讨论YAML管道，最近有很多有趣的创新。

More articles:


All Articles