Answers: <p>You've discovered one of the great pitfalls with TFVC. I have also not found an answer to this issue.</p>
  
  <p>The only possible option I've seen around getting code from TFVC out of different branches is to base your pipeline off the highest point of the source tree possible (i.e. the highest common parent folder of all branches) and always build using source labels. You have to do this otherwise a label based build request will checkout nothing if the labeled path(s) do not fall under the pipeline's source root path.</p>
  
  <p>A side effect of this is that in the build agent working directory the checked out code is going to land in a physical folder path that includes all the parent folders going up to the root specified by the pipeline's source root. If your build tasks are generic enough to tolerate this it might work. However, in my experience, the build tasks need to collect artifacts which will essentially be in an unknown location (based on the arbitrary branch) so you'll need something a bit smarter to get the path from which to collect said artifacts. It gets messy quickly. </p>
  
  <p>Another side effect of this is that you can't do continuous integration builds. In order to support getting code from labeled locations, the pipeline's source location is the base path of all possible branches. A CI triggered build then has no context for which instance of a project to build (i.e. which branch). While you could probably extract the branch of a commit from the commit data, you'd need more complicated build scripts to do so.</p>
  
  <p>I've found the pain of this to be far greater than just migrating to Git which allows for considerably more flexibility for building from arbitrary branches since the pipeline is based on the standard repo root from which all branches are based. Since Microsoft has done all but outright state that TFVC is going away, your time may be better invested in migrating to Git to take advantage of this and the other things it provides.</p>
  
Answers: CC BY-SA 4.0
Answers: 2020-06-17T20:47:13.810Z
Answers: 2020-06-17T20:47:13.810Z
Answers: Peter
Body: <p>I have project in DevOps TFVC not Git. I use branches, they live and die in the order of months. I want to create a build pipeline that is triggered when a commit is done on any of the branches and the agent job must map and get the relevant branch that triggered the pipeline. I have no idea how to do this. The initial setup of the pipeline seems to look like I can only map/cloak and get a static set of folders.</p>
  
Tags: <tfs><branch>
Title: How do I trigger a build pipeline on a TFVC branch commit to map and get that branch?
UserDisplayName: Lawrence Ward
ThreadText: # How do I trigger a build pipeline on a TFVC branch commit to map and get that branch?
  
  (Asked by: username_0 on 2020-06-10)
  
  I have project in DevOps TFVC not Git. I use branches, they live and die in the order of months. I want to create a build pipeline that is triggered when a commit is done on any of the branches and the agent job must map and get the relevant branch that triggered the pipeline. I have no idea how to do this. The initial setup of the pipeline seems to look like I can only map/cloak and get a static set of folders.
  
  **Tags:** tfs, branch
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2020-06-17. Score: 1 | Accepted answer
  
  You've discovered one of the great pitfalls with TFVC. I have also not found an answer to this issue.
  
  The only possible option I've seen around getting code from TFVC out of different branches is to base your pipeline off the highest point of the source tree possible (i.e. the highest common parent folder of all branches) and always build using source labels. You have to do this otherwise a label based build request will checkout nothing if the labeled path(s) do not fall under the pipeline's source root path.
  
  A side effect of this is that in the build agent working directory the checked out code is going to land in a physical folder path that includes all the parent folders going up to the root specified by the pipeline's source root. If your build tasks are generic enough to tolerate this it might work. However, in my experience, the build tasks need to collect artifacts which will essentially be in an unknown location (based on the arbitrary branch) so you'll need something a bit smarter to get the path from which to collect said artifacts. It gets messy quickly.
  
  Another side effect of this is that you can't do continuous integration builds. In order to support getting code from labeled locations, the pipeline's source location is the base path of all possible branches. A CI triggered build then has no context for which instance of a project to build (i.e. which branch). While you could probably extract the branch of a commit from the commit data, you'd need more complicated build scripts to do so.
  
  I've found the pain of this to be far greater than just migrating to Git which allows for considerably more flexibility for building from arbitrary branches since the pipeline is based on the standard repo root from which all branches are based. Since Microsoft has done all but outright state that TFVC is going away, your time may be better invested in migrating to Git to take advantage of this and the other things it provides.
  
  
  ---
  
  