我试图在提交消息中没有 Workitem ID 的情况下限制 GIT 提交。即#workitemID #123
请为 azure DevOps GIT Hooks 上的服务器端配置提出一个解决方案。
问问题
906 次
3 回答
1
自 2018 年以来，已请求Azure 服务器端的预接收挂钩，但尚未实施。
我们必须看看我们可以在 husky 的 repo 中做客户端什么，并在拉取请求上添加一些验证检查。
有一些策略可以阻止某些文件模式，但是：
推送政策它们根本不够，因为它只涵盖了一些特定的场景。
于 2020-08-27T06:00:28.183 回答
1
预接收和端口接收策略具有严重的安全隐患。最重要的是，它们还会影响性能。在服务器上运行 pre-receive 钩子是不安全的，运行它们，同时保持客户端等待，在另一个主机上传输 repo 和请求的更改可能太慢。这些影响似乎对 Azure DevOps 团队一直更为重要，特别是因为拉取请求和验证构建可以服务于类似的目的。您可以在此处为功能请求添加您的投票。
拉取请求策略将防止代码在未通过配置验证的情况下合并到分支。其中一项验证是 PR 必须与工作项相关联：
这不会阻止没有工作项 ID 的单个提交，但会确保合并到长期分支中的代码与工作项相关联。关联可以通过评论提及（例如#1234）或通过手动关联的拉取请求屏幕发生。
对我来说，这比#1234在每条提交消息上都需要一个更好，因为我倾向于对工作进行多次提交，然后将它们合并为一个。但是您的里程可能会有所不同。
从同一个分支策略屏幕，您还可以启用管道运行，该管道可以运行您想要的任何脚本，并且可以用作接收后挂钩。
这两种解决方案都不会充当预接收钩子，提交将被添加到目标存储库中，并且只有在之后才会确保代码不会被合并。
可以注册一个自定义服务挂钩以充当拉取请求策略，因此您可以启动一个 azure 函数或在某处调用 Web 服务以进行额外验证。
要启用拉取请求策略，请转到 Azure DevOps 中的分支页面并选择要保护的分支：
或者使用cli一次为多个分支az devops配置策略，如我在此处的博客文章中所述：
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"
于 2020-08-27T09:15:03.937 回答
1
Azure 存储库支持使用分支策略检查链接的工作项：
于 2020-08-27T08:52:07.273 回答