best way to parameterize git branch?
For automated CI job configuration, TC seems to do well with allowing us to select a set of branches to monitor.
However, we also need to be able to define some job configurations which are manually triggered, and the desired branch is a mandatory parameter.
There seems to be no assistance for this common scenario. Instead I apparently have to define my own configuration parameter like "BRANCH" as a select, and provide a set of static choices like:
trunk => refs/heads/master
mypatch => refs/heads/mypatch
...
I have to do this myself -- no way to get TC to use its general filltering abilities to offer a select list of available branches (and ideally even tags).
On a related note, I couldn't find any documentation for how I specify a refspec for branch + label?
Then, in the job configuration for the VCS Root I have to enter "%BRANCH%" for the "Default branch", and nothing at all for the "Branch specification"?
Please sign in to leave a comment.
Hi,
The approach in TeamCity to this task isn't usually through a mandatory parameter. Instead, the manual run will trigger on the default branch, while a custom run will allow you to check the "Changes" tab. In it, you can find the branches but also the commits available to be built on those branches.
It will not count as a mandatory parameter, though. That is not as big a requirement in many situations. If you are looking to force it as a parameter, then I'm afraid that your option is the only current possibility for this.
Branch specification is multiline. Add labels as if they were branches.
Regarding the build configuration, %BRANCH% will set that as the default branch, which only supports one branch. This will stop monitoring other branches, so it's not recommended. Configuring the parameters for the VCS Root is OK so you can share it between different configurations where the parameters are different. To trigger builds on branches through parameters, you can set the "teamcity.build.branch" parameter as a custom one and that should be enough.
Hi Denis
I'm currently setting the "teamcity.build.branch" parameter as you suggested (on a mercurial repo), which works great.
I then have a deployment build set with an artifact dependency (with "Latest successful build") on that build, where I can specify the "Build Branch" to use. This again works 100% for various named branches, EXCEPT for "default" branch.
It looks like there's some confusion between "default" and "<default>". I have also noticed the original build's branch labels look a bit different (darker blue) between explicitly specifying "teamcity.build.branch" to "default", and just leaving it blank so it picks up the mercurial VCS's <default> branch: "default". See below:
I'm currently using TeamCity Professional 2019.1 (build 65998). Any advice would be appreciated.
Hi Johan,
Default and <default> are indeed two very different things. "default" is just that as a string, while "<default>" is parsed in some fields as to take the default branch, whatever it is. Also keep in mind that due to the specifics of every VCS Root, everything might be different from one to the next. In particular, you are answering to a git topic, while you are using mercurial, so it might have been better to address it separately.
The content of the "Branch" field in those columns is what we call the "logical branch name". When teamcity starts a build, it sets on a branch for the VCS Root throughout the process, and we call that "logical branch name". If it matches the default, or it's configured to be the default branch set up in the VCS Root, then we use the dark blue, while all other branches use the light blue background. But if they are the same, it shouldn't matter how it was added, it should be picked up properly. If you can consistently replicate this behavior, I'd recommend opening an issue in our issue tracker: https://youtrack.jetbrains.net/issues/TW