我有一个 Azure Devops 管道,它运行一个 powershell 脚本,该脚本又调用许多其他 powershell 脚本。它调用的函数之一使用 Start-Process 调用 MSDeploy 以将版本移动到 Azure 应用程序服务上。
这通常工作正常,但偶尔会因为我们在部署过程中失去与应用程序服务的连接而停止。我通过在完成时检查进程 ExitCode 来处理此问题,并且 - 如果它非零 - 我将再次重试该操作最多 3 次。这样的工作始终确保部署成功完成。
尽管在本地管理此故障,管道中的父阶段始终将其解释为错误,并拒绝进入下一个阶段。有谁知道我如何以一种允许我检查它是否像这样工作而不杀死管道的方式调用 Start-Process ?我不想标记阶段以忽略收到的任何错误,以防万一出现我无法克服的连接真正故障。
参见下面的函数。检查 $proc.ExitCode 的值是确定它是否完成的可靠方法,但我无法阻止错误在发生时冒泡到阶段。
function DeployService([string]$ServiceName, [array]$msdeployArgs) {
[int]$i=1
[bool]$Succeeded = $false
Write-Host("Deploying service [{0}] now..." -f $ServiceName)
for(;$i -le 3;$i++)
{
$proc = Start-Process $WebDeployFilePath -NoNewWindow -Wait -ArgumentList $msdeployArgs -PassThru
$handle = $proc.Handle
$proc.WaitForExit();
if ($proc.ExitCode -eq 0) {
$Succeeded = $true
break
} else {
Write-Host("Deployment of [{0}] failed with exit code [{1}], will retry up to 3 times" -f $ServiceName, $proc.ExitCode)
if ($i -lt 3) {
$Error.Clear()
Start-Sleep -Seconds 5
}
}
}
return $Succeeded
}
父阶段继续完成,但 Powershell 任务被标记为错误,因此不会调用下一个阶段。
在 Capturing standard out and error with Start-Process
中找到了解决方案Azure 步骤错误只是因为我们正在执行的进程将信息写入了 stderr。因此,将以下内容添加到 Start-Process 命令可以抑制这种情况,并允许我们确定是否存在致命问题。
就我而言,检查非零 ExitCode 足以确定本地问题,如果我的重试不起作用,我只是通知调用代码操作失败。如果失败以这种方式冒泡,则调用代码会引发异常。
-RedirectStandardError "ErrorOut.txt"