Hello all,
Our team wants to create a policy which will automatically allow certain source control folders to get checked in without ANY checks (e.g. documentation, etc.), but the remaining items will still be processed through the normal Code Analysis policy, etc.
My thought was to create a new "Path Policy" which determines the path of each item in source control (VersionControlPath.GetFullPath(change.ServerItem)) that is being checked in - if an item falls under one of the predefined "don't apply normal policies" paths, no further policy checks would be applied to that item.
The most feasible aproach I came up with was for the "Path Policy" to just force an immediate check-in on any children of the "don't apply normal policies" paths, thus circumventing the remaining policies. This seems like it should be possible, but I haven't found any documentation regarding such functionality.
The second approach (which most likely would just be a huge PITA) would be to have one "Master Policy" which would perform the path check, and then load the remaining policies internally and apply them to the items in the changeset that weren't children of the "don't apply normal policies" paths. This is definitely the less desirable approach, as it would be much more complicated, and the remaining policies would not be shown in the Check-in Policy list (since the "Master Policy" would apply the other policies internally).
In either scenario, the "Path Policy" would need to be the first policy listed under the Source Control Settings > Plug-in Policy list.
I would love to hear from anyone that has some thoughts on this conundrum =)
One Policy to Rule Them All?
adb444
Leo,
I can definitely see why you would want a "Master Policy", but the current policy framework does not support this. Technically, you could implement your first option (the policy does the check-in), but I would not advise doing this. The tough issue here is when do you do the check-in Policies are evaluated whenever the user selects the policy channel in the Pending Changes tool window. Clearly, you do not want to cause a checkin to happen at that point. As a policy writer, currently you cannot distinguish the context when the Evaluate method is called (i.e. was it from the checkin operation or when the user selected the policy channel).
As you observed, policies are all equals and apply to the entire team project for this version. I am pretty sure your second option cannot be done because you can not directly access the other policies from your policy.
I would be interested in how you would like check-in policies to work for the next version. There are all types of possibilities around rule based enforcement of policies like chaining, applying on per folders basis, etc. What would you like to see
Ed
Blog