Azure DevOps 多阶段管道等待批准 [英] Azure DevOps Multi-Stage Pipelines Stuck Waiting for Approvals
问题描述
我将托管 Azure DevOps 与 Azure Git Repos 中的代码一起使用.我们曾经使用基于 UI 的经典"管道编辑器,但现在正在为我们的构建/发布阶段转向 YAML 模板.
过去我配置了 CI/CD,这样当代码通过拉取请求提交到主分支时,它会触发构建,然后是开发部署.其他发布阶段将在代码移动到该阶段之前等待批准.新版本将取消任何尚未部署到各自环境的先前版本.
在 YAML 部署阶段,我发现当 master 分支触发构建时,它会部署到开发环境,但管道停留在等待状态,因为其他阶段尚未获得批准.因此,运行不会被标记为完成",最终其他阶段将超时并被标记为失败.此外,管道之前的运行不会被取消,因此多次运行会堆积在等待状态.
理想情况下,我希望看到新构建将取消管道的所有先前运行.我希望在部署到 Development 后将运行标记为完成",并且能够在事后手动部署到其他阶段.
有没有其他人想做同样的事情?难道我只是想这一切都错了,应该换一种方式吗?
目前 yaml 管道不支持手动部署到阶段.请检查此
<块引用>然后将停止构建的权限设置为允许用户项目集合构建服务(项目名称),
I'm using hosted Azure DevOps with our code in Azure Git Repos. We used to use the "Classic" UI-based pipeline editor, but are moving to YAML templates for our build/release stages.
In the past I configured CI/CD so that when code is committed to the master branch via a pull request, it would fire off a build and then a Development deployment. The other release stages would wait for approval before the code moved to that stage. A new release would cancel any previous releases that haven't been deployed to their respective environments.
With YAML deployment stages what I'm finding is that when the master branch triggers a build, it deploys to the Development environment, but the pipeline is stuck in a waiting state because the other stages haven't been approved. As a result, the run isn't marked as "complete", and eventually the other stages will time out and be marked as failed. Additionally, previous runs of the pipeline are not cancelled, so multiple runs are stacked up in a waiting state.
Ideally what I'd like to see is that a new build will cancel all previous runs of the pipeline. I'd like to see the run marked as "complete" once it deploys to Development, and be able to deploy to other stages manually after the fact.
Has anybody else out there wanted to do the same thing? Am I just thinking about this all wrong and should be doing it a different way?
Manually deploy to stages is not support in yaml pipeline currently. Please check this open issue.
You can try adding dependsOn and condition for each stage. For below example yaml pipeline. Stage Build will start to run only after stage Start successfully complete, Then Stage Build will wait for approval, Stage Release willnot be triggered until Stage Build is approved and successfully finished.
You can define the pr trigger and set autocancel=true
(the default is true)to cancel previous runs if new changes were pushed to the same pr.
The batch property for trigger
can achieve a similar effect. It will not start a new run if the current pr in still in building.
trigger:
batch: boolean # batch changes if true (the default); start a new build for every push if false
branches:
include:
_
pr:
autoCancel: true
branches:
include:
- master
stages:
- stage: Start
jobs:
- job: A
pool:
vmImage: windows-latest
steps:
- powershell: |
echo "i am job a"
- stage: Build
dependsOn: Start
condition: succeeded()
jobs:
- deployment: Dev
displayName: deploy Web App
pool:
vmImage: 'Ubuntu-16.04'
# creates an environment if it doesn't exist
environment: 'Dev'
strategy:
# default deployment strategy, more coming...
runOnce:
deploy:
steps:
- script: echo "i am dev environment"
- stage: Release
dependsOn: Build
condition: succeeded()
jobs:
- deployment: Environ
displayName: deploy Web App
pool:
vmImage: 'Ubuntu-16.04'
# creates an environment if it doesn't exist
environment: 'Environment'
strategy:
# default deployment strategy, more coming...
runOnce:
deploy:
steps:
- script: echo "i am Environment environment"
You can add a powershell task at the top of your pipeline to call build api. Below scripts get all the in progress builds and cancel them except current build.
- task: PowerShell@2
inputs:
targetType: inline
script: |
$header = @{ Authorization = "Bearer $(system.accesstoken)" }
$buildsUrl = "$(System.TeamFoundationCollectionUri)$(System.TeamProject)/_apis/build/builds?api-version=5.1"
echo $buildsUrl
$builds = Invoke-RestMethod -Uri $buildsUrl -Method Get -Header $header
$buildsToStop = $builds.value.Where({ ($_.status -eq 'inProgress') -and ($_.definition.name -eq "$(Build.DefinitionName)") -and ($_.id -ne $(Build.BuildId))})
ForEach($build in $buildsToStop)
{
echo $build.id
$build.status = "cancelling"
$body = $build | ConvertTo-Json -Depth 10
$urlToCancel = "$(System.TeamFoundationCollectionUri)$(System.TeamProject)/_apis/build/builds/$($build.id)?api-version=5.1"
echo $urlToCancel
Invoke-RestMethod -Uri $urlToCancel -Method Patch -ContentType application/json -Body $body -Header $header
}
In order your pipeline to have the permission to cancel the current running build. You need go to your pipeline, click on the 3dots and choose Manage security
Then set the Stop builds permission to Allow for user Project Collection Build Service(projectName),
这篇关于Azure DevOps 多阶段管道等待批准的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!