如何解决服务器端的Azure git签入策略预接收策略
我正在尝试限制GIT提交，而在提交消息中没有Workitem ID。即#workitemID＃123
请为azure DevOps GIT挂钩上的服务器端配置提出解决方案。
解决方法
Azure仓库支持使用分支策略检查链接的工作项：
,
Azure服务器端的预接收挂钩具有been requested since 2018，但尚未实现。
我们必须研究在我们的仓库中如何用哈士奇做客户端，还要在请求请求中添加一些验证检查。
有policies to block certain file patterns，但是：
,仅根据一些特定情况推送策略是不够的。
预接收和端口接收策略具有严重的安全隐患。最重要的是，它们也会影响性能。在服务器上运行预接收挂钩并不安全，因此在转移回购协议的同时，在保持客户端等待的同时，在另一个主机上运行它们，同时使客户端等待，请求的更改可能会太慢。对于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"
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。