18

I've got a CI build pulling feature branches from Github and building/packaging them into a local folder, using a folder naming convention based on the project, branch and build number.

For named branches (feature1, feature2) this is working great.

The problem is that when I do a commit to the master, TeamCity exposes teamcity.build.branch as <default> - which means when the build step expands

E:\Packages\MyProject\%teamcity.build.branch%\

it's ending up with E:\Packages\MyProject\<default> - which is then crashing the build step because it isn't a valid Windows path.

I can see the master branch name in the fully-qualified build parameter:

teamcity.build.branch                         <default>
teamcity.build.checkoutDir                    C:\TeamCity\BuildAgents\agent-mulder\work\2151838a7933464d
teamcity.build.default.checkoutDir            2151838a7933464d
teamcity.build.id                             16347
teamcity.build.vcs.branch.github_myproject    refs/heads/master

but ideally I need to get master as the teamcity.build.branch for use in my build steps.

Can I transform the parameter at runtime? Override the behaviour? I've even tried setting the VCS branch name to DO_NOT_USE in the hope that "master" would no longer match the default - but this doesn't appear to work either.

Adam Ralph
  • 29,453
  • 4
  • 60
  • 67
Dylan Beattie
  • 53,688
  • 35
  • 128
  • 197
  • 1
    I added a ticket to their YouTrack project for TeamCity, unfortunately it's being viewed as a question, not usability problem, but if we can get more people commenting it may help: http://youtrack.jetbrains.com/issue/TW-23699 – markus101 Sep 19 '12 at 20:11
  • why not add a conditional to the build script which maps `""` to `"master"`? – Adam Ralph Dec 06 '12 at 09:27

4 Answers4

4

In teamcity 7 its simply %vcsroot.branch% that returns develop.

In my case I have 

%MajorVersion%.%MinorVersion%.%PatchVersion%-%vcsroot.branch%

Which are all set in build parameters. The number format is %BuildFormatSemVer% which is the stuff above and . {0}

%BuildFormatSemVer%.{0}

Which returns

#1.0.0-develop.4
Chris McKee
  • 4,298
  • 10
  • 48
  • 83
  • Had the same problem. Seems to work great so far, any scenarios where it doesn't work the way %teamcity.build.branch% would? – angularsen Feb 05 '14 at 20:59
  • feature branches (assuming you build them like anything else) would cause issues due to the / – Chris McKee Feb 06 '14 at 14:18
  • Does using parantheses in the branch specification help? At least %teamcity.build.branch% uses only that part of the name. For example: +:refs/heads/hotfix/(\*) +:refs/heads/release/(\*) – angularsen Feb 07 '14 at 07:25
  • I got into this setting up gitflow; this was a good start point http://www.tigranetworks.co.uk/blogs/electricdreams/ci-build-with-teamcity-git-and-gitflow-workflow/ to be honest I found the TeamCity documentation a bit hit & miss. Unfortunately my huge time investment is now at the previous company > – Chris McKee Feb 07 '14 at 09:24
  • This solution did not work for me. When I use %vcsroot.branch%, I always get the name of the default branch, even when building other branches. – omerkudat Nov 27 '14 at 09:44
  • @omerkudat you need to set the branch spec ala http://stackoverflow.com/a/22384276/52912 – Chris McKee Nov 27 '14 at 11:15
  • @ChrisMcKee Thanks Chris, I tried that as well and got the same result. I also tried the teamcity dot build dot branchParameter dot useDisplayName property for teamcity, and that didn't make a difference either. Finally, I just added a build step that emits ##teamcity[buildNumber ''] and that worked fine for now. – omerkudat Dec 04 '14 at 13:19
  • I've used this suggestion and it works. However, I only replace the branch with vcsroot.branch if the original branch returned "". – Dave Knight Oct 05 '15 at 16:02
3

Not ideal, but I was able to work around it by creating a new branch in git named "teamcity" and setting that as the default branch in TeamCity, it seems to require that the branch actually exist, since it worked when I created the branch, but didn't when you just entered a fake name.

Hopefully they actually fix this, because this is definitely a hack.

markus101
  • 338
  • 3
  • 5
  • 12
2

We have run into this problem several times when creating pipelines. It is the most visible when trying to automatically build feature and release branches using the Gitflow workflow. What we've been able to do was to use teamcity.build.vcs.branch.github_myproject and a regular expression in sed to sanitize the string whenever we wish to use it. This is mainly to watermark artifacts for debugging purposes.

The larger issue, at least for us, is that the TeamCity 7.1.1 version does not automatically fire off dependency builds for anything that isn't the default build in the VCS root. Obviously this is a huge pain point as we're now going to have to click manually in the tool. We haven't yet figured out a clean way to get around this other than hooks in git which use the HTTP API to call out to the proper build step.

John Bellone
  • 1,351
  • 1
  • 16
  • 29
1

I don't know if this was previously answered, or is any longer relevant.

In TeamCity 10.0.2 create a custom parameter such as %Git.Reference%. If you require a pull (or push) from TC to git, set this to "ref/head/Dev" or "ref/Head/yourbranch". Use this in your 'VCS root' reference.

John Sumich
  • 11
  • 2