Closed jycouet closed 6 years ago
@DavidParks8 do you know about this? :o
Yep, I'm quite familiar with it. It's where some extra documentation in your readme would come in handy. That error tells me that the vsts security model is correctly enforcing the default behavior. Specifically, the identity that your build runs as needs the correct permissions to be able to affect git repos. VSTS supports very granular security measures, and giving everyone push rights by default would be a security concern for many enterprises.
Here's an overview of how to manage git security policies in vsts/tfs: https://docs.microsoft.com/en-us/vsts/git/branch-permissions. Specifically, those with the Contribute
permission set to allow on a git repo should be able to create branches.
It would be nice to recommend some best practices around securely setting up renovate in tfs.
Some companies will want one, super tightly controlled identity running in its own isolated team project for all other team projects.
Others may want to set up a different build for each git repo. In that case, security would likely be managed with different build identities for each repo.
Yet another way to set things up would be to have one build in a team project that renovates git repos within that project.
There are many ways to slice the security permissions, but no matter what, there should be a recommendations for creating a good security boundary to prevent accidental exposure of too many permissions to the wrong identities.
Yes I see your point.
I found the perfect match.
I will put it in the doc
It's now in the doc
The message I got: