doorman
doorman

Reputation: 16949

Is there a build variable for workspace mapping

In the DevOps build template I am using the build variable $(Build.SourceBranch) to retrieve the source path of the solution in the source control. However if more than one workspace mapping is specified as seen in the picture, the variable is empty. Is there a build variable that can either return the first workspace mapping if there are more than one specified or return the source path of the solution that is being built.

enter image description here

Upvotes: 4

Views: 1336

Answers (2)

Josh Gust
Josh Gust

Reputation: 4445

Build.Repository.Tfvc.Workspace

See the documentation for a more complete list of predefined variables.

Defined if your repository is Team Foundation Version Control. The name of the TFVC workspace used by the build agent.

For example, if the Agent.BuildDirectory is c:\agent_work\12 and the Agent.Id is 8, the workspace name could be: ws_12_8

This variable is agent-scoped, and can be used as an environment variable in a script and as a parameter in a build task, but not as part of the build number or as a version control tag.

However

I'm not sure this, the actual name of the workspace, is what you're looking for. You mentioned wanting the path to the .sln, so I assume your trying to get at it so that it can be built. Correct?

In this case you should define your local (read: agent) workspace mappings into variables so that you can tell the build task to build the .sln file(s) under that path filter. Variable usage is optional, of course, but I prefer using variables to "hard coding" string values everywhere. Lets face it. Typing is hard!

Store mapping path in a var

enter image description here

Use the var in the mapping

enter image description here

Build the .sln under var mapping

enter image description here

Upvotes: 3

PatrickLu-MSFT
PatrickLu-MSFT

Reputation: 51073

No, we do not have this kind of variable to fetch workspace mappings in build agent. Just use Build.SourceBranch it will return the branch the build was queued for.

However, when there are multiple mappings, the source branch is set to the most common parent of the mappings. It there are not common parent, maybe empty.That is behaving as expected.

Here are some options that should be a workaround for your requirement:

  • Define a variable "Mapping" and use that in your build script.
  • Write a script to query the build definition object and read the mappings stored in that object.

Upvotes: 1

Related Questions