Domanda

I'm building a codebase that contains a number of Web Application projects, and we produce webdeploy packages for our build store during the build.

Thanks to the 260-character-length path limitation in NTFS, my builds fail thanks to webdeploy producing a duplicated folder structure inside the directory used to build the package, which effectively doubles the number of characters used for folders in the path. For build workspaces, which contain the name of the project and the build label, this can get pretty long.

To remedy this first problem, I redirected the package build directory using _PackageTempDir=C:\TfsTmp\Pkg\ thanks to a tip from my personal hero, Sayed Ibrahim Hashimi. This worked great, and the build now finishes successfully. However, this limits us to a single build per build agent, since all agents would attempt to use the same hardcoded path.

To remedy THIS problem, I would like to use the $(BuildAgentId) variable used in defining the Build Agent workspaces, but I don't know how to dereference this variable inside a Build Process Template. When I try, I simply emerge with folder structures on my build server like C:\TfsTmp[$(BuildAgentId)]\Pkg, or C:\TfsTmp\$(BuildAgentId)\Pkg, or similar.

Is this variable inaccessible from inside the BPT? Is there a better way to differentiate these folders? Is there perhaps a better way to have fixed my original problem in building webdeploy packages?

È stato utile?

Soluzione

The BuildAgent information should be accessible once inside the "Run On Agent" scope. Take a look at IBuildAgent and IBuildDetail to get an idea.

You might be able to get the agent ID from the URI of the agent. I haven't tested this yet, but it's a start.

String agentId = LinkingUtilities.DecodeUri(buildAgent.Uri.AbsoluteUri).ToolSpecificId;
Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top