Build.SourceBranchName does not include full name, if name includes forward slash

[ChristophLindemann]

Agent version and platform

Version of your agent: 2.105.7

Windows Server 2012 R2

VSTS type and version

On-Prem TFS 2017

What's not working?

The Build.SourceBranchName variable does not include full branch name, if branch name includes forward slash like feature/mynewfeature or bug/bug1234.

If the branch includes a forward slash, then Build.SourceBranchName will only include the last segment: mynewfeature or bug1234.

Actual:

Build.SourceBranch	Build.SourceBranchName
refs/heads/feature/mynewfeature	mynewfeature
refs/heads/bug/bug1234	bug1234

Expected:

Build.SourceBranch	Build.SourceBranchName
refs/heads/feature/mynewfeature	feature/mynewfeature
refs/heads/bug/bug1234	bug/bug1234

Build scripts

You can reproduce by creating a branch called feature/something

and have a build definition with a singe powershell script:

Write-Output "BUILD_BUILDNUMBER = ${env:BUILD_BUILDNUMBER}"
Write-Output "BUILD_SOURCEBRANCH= ${env:BUILD_SOURCEBRANCH}"
Write-Output "BUILD_SOURCEBRANCHNAME= ${env:BUILD_SOURCEBRANCHNAME}"
Write-Output "BUILD_SOURCESDIRECTORY= ${env:BUILD_SOURCESDIRECTORY}"
Write-Output "BUILD_SOURCEVERSION= ${env:BUILD_SOURCEVERSION}"

Output

2017-03-07T12:17:43.4744817Z ##[section]Starting: PowerShell Script
2017-03-07T12:17:43.6463541Z ##[command]. 'C:\Users\TFSBUILD\AppData\Local\Temp\3ed8057f-da6d-4ee2-9e51-04fb192d1677.ps1' 
2017-03-07T12:17:44.9782144Z BUILD_BUILDNUMBER = mybuild_07
2017-03-07T12:17:44.9782144Z BUILD_SOURCEBRANCH= refs/heads/feature/something
2017-03-07T12:17:44.9782144Z BUILD_SOURCEBRANCHNAME= something
2017-03-07T12:17:44.9782144Z BUILD_SOURCESDIRECTORY= D:\B\A1\_work\17\s
2017-03-07T12:17:44.9782144Z BUILD_SOURCEVERSION= 264c7662370f39ef0db9ab2c46489a686ac22724
2017-03-07T12:17:45.1344955Z ##[section]Finishing: PowerShell Script

Expected output

...
2017-03-07T12:17:44.9782144Z BUILD_SOURCEBRANCH= refs/heads/feature/something
2017-03-07T12:17:44.9782144Z BUILD_SOURCEBRANCHNAME= feature/something
...

[TingluoHuang]

@ChristophLindemann thanks for reporting, BUILD_SOURCEBRANCHNAME is a variable TFS/VSTS server set. I don't know why it set this way, i will see how can i fix it. :)

[ericsciple]

@TingluoHuang i'm not sure there is anything to do at this point. also this isnt an agent issue, the server sets. should we close the issue here?

[TingluoHuang]

We can't change the existing variable for compat reason, we can add a BUILD_SOURCEBRANCHFULLNAME if really needed. I will close the issue as Eric suggested.

[ChristophLindemann]

@TingluoHuang & @ericsciple
The BUILD_SOURCEBRANCHFULLNAME solution would be really appreciated.

For example, we use the branch name to publish intermediate API doc releases to folders named the same as the branch. Now if two people or teams use a branch name that is equal in the last segment, the builds would override each other's output.

We also use it to drop artifacts in a common drop location, so testers can access build output, while developing features in different branches.

If it is not an agent issue, I kindly ask you to add it to the TFS on prem backlog (which is not public as far as I know)

[hamptont]

+1 would also like to see support for BUILD_SOURCEBRANCHFULLNAME

[DeluxZ]

Supporting GitFlow it can be useful to have the full branch name including the "prefix" feature/, hotfix/ and release/

+1

[EwanNoble]

We would like to use full branch names to build linked template URIs for use with ARM templates

+1

[gjonespf]

@TingluoHuang & @ericsciple any chance of a workaround for this, if a feature is not made available? I'm aware this isn't really in the wheelhouse of the agent, but we have no visibility of the workload for the VSTS project itself (as @ChristophLindemann has mentioned it's not public). Some way of e.g. populating as a VSTS variable, that can be pushed through to the agent? As others have said, this pretty much makes GitFlow unworkable as it stands unfortunately.

[fleed]

That would be really helpful to identify NuGet packages coming from features, hotfixes, etc. using semantic versioning

[ericsciple]

@gjonespf We have evaluated this in the past and made the determination not to change the existing variable. That’s not to say we won’t change it, but I imagine that likelihood to be very, very low especially given how many years this behavior has existed.

There are use cases for just the very last segment (e.g. releases/m123, and just the milestone component is required).

In your scenario it sounds, it sounds like the current solution would be to add a step that performs the string manipulation and sets the variable you desire. For example:
steps:

steps:
- powershell: |
    write-host "##vso[task.setvariable variable=branch]$($env:build_sourceBranch.substring($env:build_sourceBranch.indexOf('/', 5) + 1))"
- script: set branch

[ChuckkNorris]

I can't help but feel that the current functionality is simply wrong - if I create a branch called test/awesome-branch then the branch name is test/awesome-branch, not awesome-branch.

It's quite annoying to have a task group which works if they specify a branch without a slash in it, but breaks if it does.

What can we do to change your mind on this issue?

EDIT:
I understand that it could break backwards compatibility if the variable was changed, but the proposed solution of adding a Build.SourceBranchFullName variable seems perfectly reasonable.