Enforcing a Squash merge on Azure DevOps Pull Request using GitPullRequestCompletionOptions

Question

I am attempting to use the Azure DevOps Services REST API to set the PR Completion Options to enforce a squash merge on a Pull Request.

Note: I can't set a branch policy to enforce a squash merge as I am testing certain conditions to see if a squash merge is required or not and attempting to enforce a squash as if the branch policy is set for that PR only.

When I make the following call:

PATCH https://dev.azure.com/{organization}/{project}/_apis/git/repositories/{repositoryId}/pullrequests/{pullRequestId}?api-version=5.0

{
  "completionOptions": {
    "squashMerge": true
  } 
}

The response shows the value is set

Yet when attempting to complete the request, I would expect the "Squash changes when merging" checkbox to be ticked and disabled.

If I leave the form as-is and complete the merge, no squash is performed.

If I set bypassPolicy to true, I still see no difference in completion options.

So in summary, I know that the call is successful as the response is coming back with the options set, but the changes don't seem to be coming through to the Pull Request in Azure DevOps.

Answer 1

You could use a policy that enforces this.

If you go to branches in DevOps, select your branch -> policies you can allow only squash merges:

This should make all pull requests into the branch bound by the policy to be done using squash merge.

Here's how it works for Set auto-complete:

Answer 2

Microsoft responded in the developer community forums with the following answer.

In this case there is a difference between expected behavior in the UI and via the REST endpoint. Setting squashMerge in completion options tells the PR to complete with a squash only if you complete it with the REST endpoint. In the user interface we respect user settings to enable users to choose what they would like to do (if there is no policy enabled). In this case, you did not enable a policy so a user can either squash or not. The users preference actually supersedes what you do with the REST API. If they squash merged the previous PR we will remember this and create the same default for them on the next PR.

TLDR: You cannot necessarily control the form default values with the REST endpoint and should use policy to enforce squash merge (or expect your users can set the checkbox or not depending on their preference, but we do not force a default).