skip to Main Content

My QA team has asked me to prevent pull requests from being merged until the associated work items have been marked as resolved (meaning the testing did not discover defects.) I already require that a member of their team approves the PR, but they are concerned about someone accidentally approving the wrong PR before it’s ready. They also would like this to be automated since they are already manually managing the work items. I can’t say I disagree with their wishes.

There is a similar option to automatically close linked work items when the PR is merged, but this seems backwards to me – I can’t merge the changes into the next release until the work items are resolved and properly documented.

I checked the built-in branch policies, and none of them meet my requirements. The closest option is to require work items to be linked, but this alone does not prevent merging before testing is completed.

Is what they’re asking for an acceptable use of branch policies? Or is our workflow just incompatible with this platform?

2

Answers


  1. Updated on 12/19

    For this scenario that you would like to validate the pull request with the specific work item state. I suppose that you could add a branch policy of Build Validation.

    enter image description here

    You could add the ps script below in powershell task to check the work-item state linking to your target 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
    }
    
    

    Only when the build succeeds, your pr could be complete.

    ==============================================================

    I suppose that you could check the setting for Check for linked work items.

    You could set the policy with screenshots below. And you could also set the policy with rest api."type":{"id":"40e92b44-2fe1-4dd6-b3d8-74a9c21d0c6e"} this type id in the body below is by design.

    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"}]}}
    

    enter image description here
    enter image description here
    enter image description here

    Login or Signup to reply.
  2. Currently, there is no build-in feature to meet your requirements directly.

    As a work around, for your scenario, I would suggest use Branch Policy Check for comment resolution

    Enable this feature on your target branch.

    enter image description here

    Whoever creates the PR, ask him to leave a comment to check the related WIT to be resolved. The person who creates the PR could use "#" to mention the WIT

    enter image description here

    By checking the WIT to be resolved, PR approvers could resolve the comment to allow the merge.

    enter image description here

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search