Reputation: 14766
I was wondering whether I should post this here or not, but then I saw other similar posts on TFS here and they did not solve my problem so I decided to go ahead and post it.
I am trying to fix a TFS box set up by an ex colleague. I have not used TFS in any other capacity other than checking files in'/out from it till date.For the purpose of this exercise I have created a simple winforms project with only one form and a hello world alert on form load which I am attempting to check-in into TFS. We have gated check-in enabled and we also disallow users from bypassing build validations as it can be seen highlighted in the red box here below.
Now the problem is all gated check-in attempts fail with an error:
Access Denied: User 'myOrgDomain\user.name' needs Override check-in
validation by build permission for the following build definition(s). DefnName
The message prompt I get saying it is a partial succeed
When I open the build I see this
While I checked this online I found the solution was to allow users to Bypass valdiations by enabling the check box which is grayed out. I dont want this to be the case. Is there a way I can keep the bypass validation disabled and still have my gated check in work?
This has me completely stumped and I can't figure out what could have gone wrong. Any pointers on where to look in my logs to find out what is going wrong would also probably help. The logs do say that the build has succeeded without warnings or errors.
Upvotes: 3
Views: 4527
Reputation: 123
I ran into the same problem you mention. The security setting you want to set is for the build itself as opposed to anything on the TFS box. What worked for me is right-click the build while in Visual Studio, and select the Security... option. Then, I ensured that my build service accounts had access to the "Override check-in validation on build" permission. It's not about the TFS users being allowed to override check-in. The message is really about whether the Build Service user has the capability to override check-in. For this to work, you would have to be a member of the Project Collection Build Service Accounts group.
I wondered if this would cause TFS to then override and check-in every time (even if a build fails), so I deliberately broke my build and tried it with this permission set. It did not allow my check-in to continue (i.e. failed appropriately).
In my case, I have multiple builds. It was insufficient to just allow the "Override check-in validation on build" for just the solution I was working with. For some reason, I had to do the same for all of my other builds. I have not been able to find documentation on why this is the case.
Upvotes: 0
Reputation: 115027
[TestProject]Builders, [TestProject]Administrators & [TestProject]Contributors, I have Deny checked, for [TestProject]Readers I have it blank..
Since deny overrules any grants and since almost every user is a member of the Readers or Contributors group you will run into trouble. Since users can only by-pass check-in validation when they have their permission explicitly granted, there is no need to set any deny rule.
So to solve your issue:
You can specify two explicit authorization settings for permissions in Team Foundation Server: Deny and Allow. There is also an implicit authorization that neither sets the permission to Allow nor sets the permission to Deny. This authorization is an implicit Deny setting that is referred to as Unset.
Upvotes: 1
Reputation: 8544
Something fishy is going on in your setup. The access to the flag that is presented in your screenshot is controlled by the Build-permission "Override check-in validation by build". Since it's not set as a permission, but is apparently set as an option, you 're in a deadlock situation.
I would try to temporary enable this flag (right-click Team Explorer on "Builds", choose "Security" and set the permission for your user), then checkbox should get enabled & I 'd expect it to be checked. I'd uncheck the checkbox by hand and let a build run. Then I would disable the permission.
Hopefully now VS will keep this option.
If this failed, I would file a bug in MS.
Upvotes: 0