1

I want a release pipeline to create a pull request in the develop branch to pull from the feature branch.

When the task attempts to create the pull request I receive:

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,

"Allow scripts to access the OAuth token" is ticked.

When I go to the branch security section of the develop branch, I have the option to add accounts with contribute permission, but I can't see any account that matches Build\\f00fffff-00ff--0fff-ff0f-0000f00ff00f. I've tried adding contribute permissions for the Project Collection Build Service Accounts groups, Project Service Accounts and Build Administrators, but it's still not working.

How do I add the appropriate permissions?

Dicky Moore
  • 956
  • 3
  • 10
  • 32
  • 1
    This is an interesting workflow -- I would have expected a release pipe to be set to trigger by (eg) a real user's pull request completing and triggering CI/CD, rather than the other way around from a service account. Are you constrained by an organisational workflow policy, or is there some other reason in play for this approach? – T2PS Sep 17 '19 at 09:57
  • I'm working to a set of standards set out from a stakeholder, however, there is some flexibility, so it could be that setting the release to trigger from a pull request would be acceptable. One of the requirements is that the pipeline has completed before the code review takes place, so if the pipeline fails the code reviewer doesn't even need to look at it. Is this feasible, do you think? And if so are there any tutorials for achieving this you could recommend? Thanks – Dicky Moore Sep 17 '19 at 11:36
  • 1
    @DickyMoore Use branch policies with required builds. Your users should open PRs when they're done and let the build run as part of the PR. You're trying to do things backwards. There's no reason to not start code review while the build runs. If the build fails, the submitter can update the PR; that doesn't invalidate existing code reviews. – Daniel Mann Sep 17 '19 at 23:35
  • Branch policies are the way to go here. Our setup is based on the prerelease version of YAML pipelines, so it's probably best if I don't give you an answer based around the deprecated schema... but the basic flow is a PR automatically triggers one or more validation builds, we have a dashboard based off ADO's REST APIs to periodically check the policy evaluations that result (for users who want to see passing builds before starting reviews) and then the CI/CD pipe set to trigger on changes to the master branch. – T2PS Sep 18 '19 at 03:04
  • @DickyMoore, Is there any progress in your question? Can my answer solve your problem? – Frank Wang-MSFT Sep 26 '19 at 09:46

1 Answers1

3

You should go to your repository settings, and you will find a new user named Projectname Build Service(Organizationname). After setting the user’s Contribute to pull requests permission as Allow, your release pipeline can create the pull request without the error message. enter image description here

And your new pull request will display in the Pull Request -> Active web page, like following. enter image description here

Frank Wang-MSFT
  • 1,367
  • 6
  • 6