【发布时间】：2020-12-15 23:25:50
【问题描述】：
我试图在提交消息中没有 Workitem ID 的情况下限制 GIT 提交。即#workitemID #123
请为 azure DevOps GIT Hooks 上的服务器端配置提出解决方案。
【问题讨论】：
标签： azure-devops githooks azure-git-deployment azure-service-hooks
【发布时间】：2020-12-15 23:25:50
【问题描述】：
Azure 服务器端的预接收挂钩有been requested since 2018，但尚未实现。
我们必须看看我们可以在 husky 的 repo 中做客户端什么，并在拉取请求上添加一些验证检查。
有policies to block certain file patterns，但是：
仅仅推送政策是不够的，因为它只涵盖了一些特定的场景。
【讨论】：
【讨论】：
-
这可以被视为仅链接答案。这些在 Stack Overflow 上不太受欢迎，因为链接断开时信息可能会丢失。
预接收和端口接收策略具有严重的安全隐患。最重要的是，它们还会影响性能。在服务器上运行 pre-receive 钩子是不安全的，运行它们，同时让客户端等待，在另一个主机上传输 repo 和请求的更改可能太慢。这些影响似乎对 Azure DevOps 团队一直更为重要，特别是因为拉取请求和验证构建可以服务于类似的目的。 You can add your votes to the feature request here.
Pull Request Policies 将阻止代码在未通过配置验证的情况下合并到分支。其中一项验证是 PR 必须与工作项相关联：
这不会阻止没有工作项 ID 的单个提交，但会确保合并到您的长期分支中的代码与工作项相关联。关联可以通过评论提及（例如#1234）或通过手动关联的拉取请求屏幕发生。
对我来说，这比在每条提交消息上都要求#1234 更好，因为我倾向于对工作进行多次提交，然后将它们合并为一个。但您的里程可能会有所不同。
您还可以从同一分支策略屏幕启用管道运行，该管道可以运行您想要的任何脚本，并且可以用作接收后挂钩。
这两种解决方案都不会充当预接收挂钩，提交将被添加到目标存储库中，并且只有在之后才会确保代码不会被合并。
可以注册一个自定义服务挂钩以充当拉取请求策略，因此您可以启动一个 azure 函数或在某处调用 Web 服务以进行额外验证。
要启用拉取请求策略，请转到 Azure DevOps 中的分支页面并选择要保护的分支：
或使用az devops cli 配置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"
【讨论】：