Some days ago, I got an email from a colleague about a build issue. Here is what she wrote me.
After bringing back the build agents of
___, we’ve experienced below problem
I’ve mentioned you this problem before, we’ve experienced the same when started to use
____ for first time.
Only deleting the workspaces + physical folders fixed it.
I know that many Build Master and TFS Administrators have seen the
Unable to create the workspace ___ due to a mapping conflict. issue, but it could be useful to review why it happens.
Workspaces are stored as configuration data in TFS databases, and TFS client forbids having overlapping mappings between different workspaces. So a local (physical) folder, like
C:\work on machine
MyPC01, cannot belong to more than one workspace.
After you reconfigure a build server, all “old” workspaces are still recorded in the database, but the Agent Id changes. In the early stages of a build, the workflow creates a workspace to get the source code and the name for this new workspace is generated using the Agent Id (actually
38_6_Build01). Actually it is smarter, if a workspace with the same name already exists, the found workspace is re-used.
The workspace mapping is based on Agent working directory, which in that specific case is
D:\B\$(BuildDefinitionId): you see that the mapping has no Agent Id in it.
So, if the old configuration had a
38_6_Build01 workspace mapped to
D:\B\38, the first run for the rebuilt agent will try to create a workspace
38_8_Build01 mapped on the same
D:\B\38 folder, then the error.
D:\B\$(BuildDefinitionId)as the working directory for Agents is a bad idea.
$(SystemDrive)\Builds\$(BuildAgentId)\$(BuildDefinitionPath)which is unique per Build Agent.
Build Masters have often issues with the length of some paths and they try to squeeze every possible byte, but it is best to educate developers to avoid deep folder structures that incur in the 260 character limit. Discussing in depth this topic requires a full post.
Another source of problems could be the Build Definition not using the
$(SourceDir) macro in the Source Settings tab. In this case the mapping will entirely skip the Agent configuration, so it is up to the Build Master avoiding clashes between different build definitions.