在Azure Devops中,如何创建分支策略以要求在合并PR之前解析链接的工作项?

moiiocjp  于 2022-12-19  发布在  其他
关注(0)|答案(2)|浏览(161)

我的QA团队要求我防止合并拉取请求,直到关联的工作项被标记为已解决(意味着测试没有发现缺陷。)我已经要求他们团队的一名成员批准PR,但是他们担心有人在PR准备好之前不小心批准了错误的PR,他们也希望这是自动化的,因为他们已经在手动管理工作项了。我不能说我不同意他们的愿望。
有一个类似的选项可以在合并PR时自动关闭链接的工作项,但这对我来说似乎是倒退了--在工作项被解决并正确记录之前,我无法将更改合并到下一个版本中。
我检查了内置的分支策略,没有一个符合我的要求,最接近的选择是要求工作项被链接,但是这本身并不能阻止在测试完成之前进行合并。
他们所要求的是一个可接受的分支策略的使用吗?或者我们的工作流程只是与这个平台不兼容?

5kgi1eie

5kgi1eie1#

12月18日更新

对于这个场景,您希望使用特定的工作项状态来验证拉取请求,我假设您可以添加一个分支策略Build Validation

您可以在powershell task中添加下面的run ps脚本,以检查链接到目标pr的工作项状态。

# Define organization base url, PAT, linked wit, Target WIT state and API version variables
$orgUrl = "https://dev.azure.com/{yourORG}/{yourPROJECT}"
$pat = ""
$queryString = "fields=system.state&api-version=7.0"
$witID = {YourWitID} 
$TargetState = {yourWITstateForPRapproval}

# Create header with PAT
$token = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes(":$($pat)"))
$header = @{authorization = "Basic $token"}

# Get the linked wit state
$projectsUrl = "$orgUrl/_apis/wit/workitems/$witID?$queryString"
$field = Invoke-RestMethod -Uri $projectsUrl -Method Get -ContentType "application/json" -Headers $header | ConvertTo-Json | ConvertFrom-Json | Select-Object -ExpandProperty fields

write-host $field

$witstate = $field.'System.State'

Write-Host $witstate

#Compare the wit state with target approval state

if ($witstate -eq "$TargetState" ) {
    Write-Host "Check Succeeded"
}
else {
    Write-Host ("Check Failed")
    exit 1
}

只有当构建成功时,你的公关才算完成。

我想您可以检查Check for linked work items的设置。
你可以用下面的截图来设置策略,也可以用rest API来设置策略,下面正文中的类型id是设计好的。
POST https://dev.azure.com/fabrikam/fabrikam-fiber-git/_apis/policy/configurations?api-version=7.0

Body
{"type":{"id":"40e92b44-2fe1-4dd6-b3d8-74a9c21d0c6e"}, 
"revision":1,
"isDeleted":false,
"isBlocking":true,
"isEnabled":true,
"settings":{
"scope":[{"repositoryId":"$(yourRepo)",
"refName":"refs/heads/$(yourBranch)",
"matchKind":"Exact"}]}}

第一节第一节第一节第二节第一节第三节第一

cgfeq70w

cgfeq70w2#

目前,没有内置功能可以直接满足您的要求。
作为一种变通方法,对于您的场景,我建议使用分支策略检查来进行注解解析
在目标分支上启用此功能。

无论是谁创建的PR,请他留言查看需要解决的相关WIT。创建PR的人可以使用“#”表示WIT

通过选中要解决的WIT,PR审批者可以解决备注以允许合并。

相关问题