0

By default, when a queued build is running, MSBuild calls the CoreLabel task to label the source files that were included in the build - how do I control where this label is created?

Basically, I would like the label to be created at the root of the Team Project (i.e. folder "Client" below), however it appears that the label is created at the root of the working folder for the workspaces (i.e. Project 1\Development\Sources):

$                     <-- Project Collection
+- Client             <-- Team Project
  +- Project 1        <-- Project
    +- Deployments    <-- Assets for a deployment
      +- 1.0.0.0
      +- 1.1.0.0
    +- Development    <-- Development Branch
      +- Source       <-- Dev Build Definition working folder mapped here.
    +- Environment    <-- Scripts, etc. for deployments.
    +- Main           <-- Main Branch
      +- Source       <-- Release Build Definition working folder mapped here.

Within the build definitions, we have specified a "Working folder" in the workspace at the "Source" folder level for either Development or Main depending on the build type.

Looking at the build logs, it looks like the label should be created at the Client level:

Task "Label" (TaskId:42)
  Label TeamFoundationServerUrl="http://TFSServer:8080/tfs/DefaultCollection"
        BuildUri="vstfs:///Build/Build/4538" 
        Name="Nightly_20110303.5" 
        Scope="$/Client" 
        Recursive=True 
        Comments="Version-1.0.0.0 Requested-xxx Get-T Branch-Development"
        Version="WCATQCDEV-BLD_35_8"
        Child="Replace"
        Files="$/" (TaskId:42)
  Label Nightly_20110303.5@$/Client (version WCATQCDEV-BLD_35_8) was successfully created. (TaskId:42)

However, even though Files is set to $/ the label is still created at the working folder level. According to the documentation, the Files parameter is supposed to specify which files are included in the label, but clearly it's not working quite as we'd like.

I've successfully modified the comment that is created using the BeforeLabel task setting the LabelComment property, however, trying to set the LabelFiles property in the same task to something like $/Client doesn't seem to affect the location the Label is created at, and also seems to end up mangled to %26/Client in the log when it calls the Label method.

Zhaph - Ben Duguid
  • 26,785
  • 5
  • 80
  • 117

1 Answers1

2

Label will be created for the Source Control Folder specified in workspace tab of that particular build type.

If you are specifying "Development" as the Source Control Folder in Build Type, then Label will be created only for the files under "Development" folder.

The label is identified not only by name, but also by so-called "scope", where scope is the actual path within which the label name is unique.

If your label scope is "$/project", that the label name is unique within Project; and when scope is "$/Project/Development", the label name is unique within Development.

Scope="$/Client"

Above entry in your log file doesn't mean that it's creating label for files under $/Client, but it actually means that the label created is unique in $/Client.

The scope also allows users to create multiple labels with same name within the same project. For ex: Two labels with same name called "Test" can be created for different scopes in same project("$/project" and "$/Project/Development").

Jehan33
  • 3,780
  • 2
  • 21
  • 16
  • Thanks for replying - yes, I realise that the `scope` defines effectively the scope of the label - we've been using that quite nicely to have mutliple labels with the same name in different Team Projects I was hoping that the `files` would enable me to control where the Label is created. So basically, we'll need to create a seperate build task that goes and labels everything from the root? Because if I run tf label from a command line, I can set the label anywhere in TFS using the ItemSpec parameter, regardless of any working folders I've configured? – Zhaph - Ben Duguid Mar 05 '11 at 10:55
  • I think you are working with TFS2010. Are you using Default Build Template(DefaultTemplate.xaml) or Upgrade Build Template(UpgradeTemplate.xaml)? – Jehan33 Mar 05 '11 at 15:40
  • Yes, we're working with TFS2010, but I believe we're using the 2008 style build projects - I've got a .proj file with a number of tasks in it, mostly because we didn't have the time at the beginning of the project to learn the new Workflow based way of doing things :( I've therefore possibly miss-tagged this question. – Zhaph - Ben Duguid Mar 07 '11 at 15:25