如何在Azure Devops管道中使用PowerShell根据条件触发代理作业

我有一个PowerShell，如下所示：

echo "Hello-World"
$MyVariable = "Proceed"
echo $MyVariable

我想做的是：

如果MyVariable仅为“procedue”，则代理Job2应运行

我使用了PowerShell任务，并将变量名指定为MyVariableOutput

我在代理Job2级别完成了以下配置

你能告诉我我该如何处理这些条件吗：

仅当代理Job1上的Powershell脚本生成作为MyVariable的值的继续时 代理Job2将运行

---

注意：代理Job1和代理Job2是同一发布管道的一部分

如果希望使用GUI配置管道，则必须运行脚本，通过调用此脚本将MyVariable添加为变量，而不是临时变量。因为在

代理作业1

完成后，您刚才用

$MyVariable=“procedure”

定义的变量将不会传输到下一个代理作业。

代理作业1

和

代理作业2

彼此独立

---

在代理作业1中：

配置2个powershell任务

（1）第一个用于定义具有值的变量，并将其设置为输出变量：

echo "Hello-World"
echo "##vso[task.setvariable variable=MyVariable;isOutput=true]Proceed"
echo $MyVariable

不要忘记在此任务中指定其

引用

名称MyVariableOutput

（2）第二个作业用于将此

输出变量添加到
变量中，然后
代理作业2
可以访问它：

$connectionToken="{token}"
$urlget = "https://vsrm.dev.azure.com/{org}/{project}/_apis/release/releases/$(Release.ReleaseId)?api-version=5.1"
$base64AuthInfo = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes(":$($connectionToken)"))
$getdef = Invoke-RestMethod -Headers @{Authorization=("Basic {0}" -f $base64AuthInfo)} -Method GET -ContentType application/json -Uri $urlget 
##Write-Host Pipeline = $($getdef | ConvertTo-Json -Depth 100)
$MyVariable=@"
    {
      "value": "$(MyVariableOutput.MyVariable)"
    }
"@
$getdef.variables | add-member -Name "MyVariable" -value (Convertfrom-Json $MyVariable) -MemberType NoteProperty -Force -PassThru

$getdef = $getdef | ConvertTo-Json -Depth 100
$getdef | clip
$urlput = "https://vsrm.dev.azure.com/{org}/{project}/_apis/release/releases/$(Release.ReleaseId)?api-version=5.1"
$putdef = Invoke-RestMethod -Uri $urlput -Method PUT -Body $getdef -ContentType "application/json" -Headers @{Authorization=("Basic {0}" -f $base64AuthInfo)}

上述脚本将创建一个变量
MyVariable
，其值为
procedure


在
代理作业2
中，按如下所示配置条件：

eq(variables['MyVariable'],'Proceed')

您可以看到代理job2可以成功运行，因为它检测到
MyVariable
的值为
procedue

谢谢您的回复。如果MyVariable的值为“继续”，为什么跳过代理Job2？如果代理Job2的值为proceed@Eddie原谅我的错误，因为我的大脑仍在周一启动序列中。谢谢：-）它工作了。只是想知道，我们是否可以在不使用单个代理设置环境变量的情况下执行此操作，即两个任务都是同一代理的一部分。@Eddie，如果只是在任务而不是代理作业中传递变量，则不需要应用如此复杂的脚本。只需像普通方法一样传递输出变量：。我在这里还有一个关于该方法的查询