5

We are adopting gitflow process in our project using Azure DevOps. I have the following scenarios:

  1. When the features branches are merged into Develop, I want to enforce squash merge strategy while completing the pull request
  2. When the Release branch is periodically synched back to Develop, I want to enforce no-ff merge, to preserve Release branch checkin history

There are two questions:

  1. Given my two requirements above, does this somehow indicate that I might be doing something wrong with respect to branches and merges

  2. Is there a facility in AzDo to provide different merge strategies (automatically) based on the source branch?

Thanks,

Chubsdad
  • 24,777
  • 4
  • 73
  • 129
  • Hi @Chubsdad did you check out below scripts, please let me know if there is any question? – Levi Lu-MSFT Feb 14 '20 at 09:13
  • Hi @Chubsdad, what you're trying to do makes total sense to me - we have exactly the same issue in our organization and I'm looking for a solution – aderesh Feb 16 '21 at 00:10

2 Answers2

1

I cannot see anything wrong with above branches and merges of gitflow process. Please check this document for more information about gitflow process.

There is no direct way to automatically choose different merge strategies based on the source branch. The workaround is that you can use pull request update rest api to set the pr to autoComplete and set the merge strategies according to the source branch. Below is an example for reference.

1, first create a build pipeline and add a powershell task to run below script. You can check here for steps to create a classic ui pipeline. For yaml pipeline you can check this document.

Below script will set the merge strategy according the the System.PullRequest.SourceBranch and enable the autocomplete for this pr. So that the pr will be automatically complete when all the requirements are met. (you need to change the if(){} part according).

    $uri = "$(System.TeamFoundationCollectionUri)$(System.TeamProject)/_apis/git/repositories/$(Build.Repository.ID)/pullrequests/$(System.PullRequest.PullRequestId)?api-version=5.1"

    $response =  Invoke-RestMethod -Uri $uri -Headers @{authorization = "Bearer $(System.AccessToken)"} -Method get 
    $userid = $response.createdBy.id
    $merge =  "rebaseMerge"

    if("$(System.PullRequest.SourceBranch)" -eq "refs/heads/release"){$merge =  "noFastForward"}

    $body =@{
        autoCompleteSetBy = @{
        id= "$($userid)"
          }
        status = "complete"
        completionOptions= @{mergeStrategy = $merge}
     }
    $bjson = $body | ConvertTo-Json

    Invoke-RestMethod -Uri $uri -Headers @{authorization = "Bearer $(System.AccessToken)"} -Method patch -ContentType application/json -Body $bjson

2, Then configure the branch policy for Develop branch. and choose the pipeline created above to set up the build validation. By setting up the build validation, the pr will trigger to run the build pipeline which created in above step. And above pipeline will change the merge strategies according to source branch.

You can also submit a feature request (click suggest a feature and choose azure devops)for this facility to Microsoft development.

Levi Lu-MSFT
  • 27,483
  • 2
  • 31
  • 43
  • Hi Levi, I believe this is not what the author wants to achieve. This approach doesn't prevent a user from canceling autocomplete and using not desired merge type. I believe they want to have an ad-hoc policy to restrict certain merge types based on a PR property like source branch. Thanks for the link- I'll create a feature request – aderesh Feb 16 '21 at 00:15
  • @aderesh this answer states, "There is no direct way...", so obviously it isn't *exactly* what the author wants to achieve. But (IMHO) this is a pretty decent workaround compared to nothing. If the user circumvents it by canceling auto-complete, then that's on them. – TTT Apr 04 '22 at 19:44
  • I am trying to use this approach but I am receiving the following error `"Invalid argument value.\r\nParameter name: Invalid pull request auto complete set by id. Valid values are either the current user identity id, or an empty guid (to unset auto complete)` have you faced this before? I guess that the user for the System.AccessToken is not the same as the PR author (me) right? – luisgepeto Jul 06 '22 at 21:44
0

I don't think it's currently possible in ADO. I've found a feature request ticket and left my comment with the suggestion - the feature request.

Here is a copy of my comment:

I think this feature would be awesome. Currently, is a stack overflow related to this problem:

https://stackoverflow.com/questions/60106638/different-merge-strategies-automatically-based-on-the-source-branch
Also, I’ve checked both UI and REST API looking for a way or a workaround to achieve this but to no avail.

My generalized suggestion would be to be able to create and attach ad-hoc policy to a PR to override a branch policy. This would allow a third party tool (and/or in UI) to override policy properties like “Limit merge types” based on PR properties like ‘source branch’. For instance, if a source branch is set to “feature/somefeature”, “Limit merge types” should be Squash only. Another example, if a source branch is “integration”, don’t allow Squash Merge.

As an alternative, you can use ADO Service Hooks to trigger a custom app upon PR creation/modification (e.g. Azure Functions) to leave a comment as a reminder for a dev not to use the Squash merge type. The app can have a logic to add the comment only if PR's source branch is a specific branch. If your branch policy has Check for comment resolution set, a dev won't be able to complete the PR without resolving the comment. It's not quite what you want to achieve (there is nothing to prevent a dev to use an invalid merge type), but, hopefully, will decrease the amount of such cases. Here is an example of a custom branch policy in Azure Functions.

aderesh
  • 927
  • 10
  • 22