Azure git check-in policy pre-receive policy at server side

Question

I am trying to restrict GIT Commit without having Workitem ID in the commit message. i.e. #workitemID #123

Please suggest a solution for the server-side configuration on azure DevOps GIT Hooks.

Answer 1

A pre-receive hook on Azure server side has been requested since 2018, but is yet to be implemented.

We are having to look at what we can do client side in the repo with husky and also add some validation checks on the pull requests.

There are policies to block certain file patterns, but:

push policies they are simply not enough since it is only covering a few specific scenarios.

Answer 2

Azure repos supports checking for linked workitems with branch policies:

https://learn.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops#check-for-linked-work-items

Answer 3

Pre-receive and port-receive policies have severe security implications. On top of that they can also impact performance. Running the pre-receive hook on the server is not secure, running them, while keeping the client waiting, on another host while transferring the repo and the requested changes potentially too slow. These implications seem to have always been more important to the Azure DevOps team, especially since Pull Requests and Validation builds can serve a similar purpose. You can add your votes to the feature request here.

The Pull Request Policies will prevent code being merged to a branch without the code passing the configured validations. One of these validations is that a PR must be associated to a Work Item:

This won't block individual commits that don't have a work item Id, but it will ensure that code merged into your long-lived branches is associated to a work item. Association can happen through a comment mention (e.g. #1234) or from the pull request screen with manual association.

To me this is better than requiring a #1234 on every commit message, since I tend to do more than one commit for pieces of work and then merge them as one. But your mileage may vary.

From the same branch policy screen you can also enable a pipeline to run, this pipeline can run any script you want and can serve as a post-receive hook.

Neither solution will act as a pre-receive hook, the commits will be added to the target repo and only afterwards will policy ensure the code won't be merged.

It's possible to register a custom service hook to act as a pull request policy, so you could fire off an azure function or invoke a webservice somewhere to do extra validation.

To enable a pull request policy, go to the branches page in Azure DevOps and pick the branch to secure:

Or use the az devops cli to configure a policy for multiple branches at once as explained in my blog post here:

az extension add --name "azure-devops"
az login

az repos policy create --org {your org} --project {your project name or guid} --config "path/to/config/file"

More docs can be found here as well.