Our code sits in one TFS project, and we have multiple other projects that contain data:
$/
- $/Code
- $/Data1
- $/Data2
We have defined a gated check-in build to run on each check-in to $/Code. We don't care about each individual project's data for that matter, since we only want to build the shared $/Code project.
The problem is that when a user checks-in a code change together with data change, i.e. alters both $/Code and $/Data1, the build fails because we don't have mapping for $/Data1 in our build definition: "No appropriate mapping exists for $/Data1/file.txt".
This can theoretically be solved by mapping each $/DataN, but it's a lot of content to map and I want a simpler solution. Can I somehow tell TFS to just ignore unmapped files in the shelveset? Something like this maybe?
As you've probably gathered, this is not possible at the moment. You could instruct your developers to check in
$/Code
separately from any$/DataN
. You could even setup a Checkin Policy which will warn the developers of the issue.If you're really only interested in the code building, then I'd opt for such a solution.
As to why it works as it does... The build agent unshelves the shelfset that is assigned to your user, shelves it again under it's own name to make sure the data being built is exactly the data being checked in at the end of the build. This would fail if not all data was present in the current workspace. At the end the build checks in the shelveset that's made under its name.
Because of these details, I do not expect this feature to be added any time soon, there is a chance of creating nasty inconsistencies if the build is unable to validate that the code it is about to check in is really the code that it just built. Auditors would have a fit :).