【发布时间】:2019-09-17 09:12:04
【问题描述】:
我想要一个发布管道在开发分支中创建一个拉取请求以从功能分支中拉取。
当任务尝试创建我收到的拉取请求时:
TF401027: You need the Git 'PullRequestContribute' permission to perform this action. Details: identity 'Build\\f00fffff-00ff--0fff-ff0f-0000f00ff00f', scope 'repository'.","typeName":"Microsoft.TeamFoundation.Git.Server.GitNeedsPermissionException,
勾选“允许脚本访问 OAuth 令牌”。
当我转到开发分支的分支安全部分时,我可以选择添加具有贡献权限的帐户,但我看不到任何与 Build\\f00fffff-00ff--0fff-ff0f-0000f00ff00f 匹配的帐户。我已经尝试为项目集合构建服务帐户组、项目服务帐户和构建管理员添加贡献权限,但它仍然无法正常工作。
如何添加适当的权限?
【问题讨论】:
-
这是一个有趣的工作流程——我希望发布管道被设置为由(例如)真实用户的拉取请求完成并触发 CI/CD,而不是反过来服务帐户。您是否受到组织工作流程政策的限制,或者这种方法是否有其他原因?
-
我正在按照利益相关者制定的一组标准工作,但是,有一些灵活性,因此将发布设置为从拉取请求触发可能是可以接受的。要求之一是在代码审查发生之前管道已经完成,因此如果管道失败,代码审查员甚至不需要查看它。你觉得这可行吗?如果是这样,您可以推荐任何实现这一目标的教程吗?谢谢
-
@DickyMoore 使用具有所需构建的分支策略。您的用户应该在完成后打开 PR,并让构建作为 PR 的一部分运行。你试图做事倒退。在构建运行时没有理由不开始代码审查。如果构建失败,提交者可以更新 PR;这不会使现有的代码审查无效。
-
分支政策是这里的必经之路。我们的设置基于 YAML 管道的预发布版本,所以如果我不根据已弃用的模式给你答案可能是最好的……但基本流程是 PR 自动触发一个或多个验证构建,我们有一个基于 ADO 的 REST API 的仪表板,用于定期检查产生的策略评估(对于希望在开始审查之前查看通过的构建的用户),然后设置 CI/CD 管道以触发对主分支的更改。
-
@DickyMoore,你的问题有进展吗?我的回答能解决你的问题吗?
标签: git azure-devops azure-pipelines azure-pipelines-release-pipeline azure-git-deployment