如何解决服务器端的Azure git签入策略预接收策略
我正在尝试限制GIT提交,而在提交消息中没有Workitem ID。即#workitemID#123
请为azure DevOps GIT挂钩上的服务器端配置提出解决方案。
解决方法
Azure仓库支持使用分支策略检查链接的工作项:
https://docs.microsoft.com/en-us/azure/devops/repos/git/branch-policies?view=azure-devops#check-for-linked-work-items
,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 举报,一经查实,本站将立刻删除。