When my TFS build is triggered by a branch-specific check-in, why doesn't it set that branch as its source?

0
votes

My goal is to create a TFS CI Build that is triggered by check-ins on two specific branches of a project, hosted in TFVC. When I queue the build manually and type a specific branch in the "Shelveset name" field of the queue prompt, the build works as intended. However, when I check in changes from one specific branch, the build attempts to use the parent folder of the two branches as its default source, resulting in incorrect file paths throughout the build definition wherever I use the $(Build.SourceBranchName) variable.

My folder structure is as follows:

- $/MyRepo
|
| -Integration Suite
  |
  | -CurrentVersion
  |
  | -Dev

I have CI triggers turned on with path filters to include $/MyRepo/Integration Suite/CurrentVersion and $/MyRepo/Integration Suite/Dev

In the "Get Sources" task, my repository is set to $/MyRepo, and I map these server paths to the CurrentVersion and Dev local paths, respectively.

I would expect, for example, that checking in changes under the CurrentVersion branch would set the source of the build to $/MyRepo/Integration Suite/CurrentVersion, but instead it is set to $/MyRepo/Integration Suite. This means that any paths I build in the definition with $(Build.SourceBranchName) have Integration Suite where they should instead have CurrentVersion.

Am I doing something wrong? Or is my desired behavior not supported?

1
tfstfsbuildtfvc

1 Answers

3
votes

TFVC relies on workspace mappings to know what to download. The workspace mappings can encompass multiple TFVC repos across different team projects, multiple branches within a single repository, basically, whatever your heart desires. As a result, there's no way for it to understand how to dynamically change workspace mappings to be for a specific branch.

The sad reality of TFVC builds is that you need one build for every branch. This makes TFVC... er... not great for many common continuous delivery scenarios.