Pages Menu
TwitterRssFacebook

Posted by on Aug 10, 2014 in Development | 0 comments

After upgrade to TFS 2013 builds created do not execute correctly – working directory not mapped

After upgrade to TFS 2013 builds created do not execute correctly – working directory not mapped

Problem Scenario

You have an existing TFS installation with TFS Build set up, which is then upgraded to TFS 2013. From that point, new builds created with the default template (TfvcTemplate.12.xaml) may not run. Or they may run, but produce incorrect or suspect output. On examination of the Build Agent, the working directories are not being correctly mapped with AgentID or BuildDefinitionID:

BuildDefinition

One of the TFS Build settings you apply via the TFS Administration Console is the working directory to be used for builds. It’s important to ensure that each build can run in it’s own separate folder, to avoid cross-contamination of the code. Normally you would segregate using the ID of the build agent, and the ID of the build definition: for instance D:\\Builds\\$(BuildAgentID)\\$(BuildDefinitionID). At build time these values should get resolved to numbers, to guarentee a unique folder. However, for newly created builds using the new template, this isn’t happening. As you can see in the screenshot, the parameters are not being resolved.

Builds created with the previous template (TfvcTemplate.11.xaml) work fine.

Solution

It seems that the parameter names have either changed from TFS 2012 to 2013, or the code that parses them has become case-sensitive. Where before $(BuildAgentID) would work, now it has to be $(BuildAgentId) or it won’t resolve. Same for $(BuildDefinitionId).

Changing the Working Directory entry in the TFS Administration Console to use $(BuildAgentId) and $(BuildDefinitionId) will fix the problem:
WorkingDirectory

You can use the following variables in a build agent working directory:

  • $(BuildAgentId): An automatically generated integer that uniquely identifies a build agent within a team project collection.
  • $(BuildAgentName): The Display Name of the build agent.
  • $(BuildDefinitionId): An automatically generated integer that uniquely identifies a build definition within a team project collection.
  • $(BuildDefinitionPath): The team project name and the build definition name, separated by a backslash.

Hope this helps someone with a similar problem, especially if you ended up here as a result of Google search!

Post a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

This site uses cookies to help make this website better. By continuing to use this site we’ll assume you’re OK with that (implied consent).