In TeamCity 2018.1.4 (build 58724), I have a couple of projects with feature branches.
In one project, the master branch is correctly named as master, whereas in another project, no matter what I try, it remains as <default>. The feature branches are correct.
Project 'A' with problem:
VCS settings:
Correct Project 'B':
VCS settings:
I have followed this guide: https://confluence.jetbrains.com/display/TCD18/Working+with+Feature+Branches#WorkingwithFeatureBranches-Logicalbranchname
and tried this answer: Change branch name when running custom build in Teamcity
There was also a comment on another SO question (that I now can't find) that suggested removing all builds. I have tried this and it still remains <default>
If anyone has any suggestions or ideas for me to try, I'd be grateful if you'd share.
TIA.
Update 1
The "functionality" seems to be by design. In Project 'A', I have two VCS roots, whereas Project 'B' only has one. However, I am struggling to interpret the answer given: Branch name in build number
Related
Context
I have a project absed on a vcs root with the wildcard branch filter (+:*), meaning that it will trigger a build on every possible modification pushed to git.
Because we're on a migration process, our current projects have a lot of branches, and we want to start the build process on some of them.
Issue
Because the Run button of the build starts a build with default branch (AKA master), we can't run a build on a given branch, the need being to have a select box with existing branches that you can select for the build.
Already tried / Invalid solutions
A solution would be to push a dummy commit on each branch to trigger TC and make it see the branch, this way we could select the branch in the run options, but that's not a solution to us because pushing a dummy commit just for that feels wrong.
I can also use the solution provided in Select Git branch for TeamCity Build, but the issue is that we have a lot of branches with quite heavy names, and this solution allows typo, which is not what we want.
Make sure you have correctly configured branch specification in VCS Root settings. In my case:
Go to build configuration, select branch you want to build from and press run:
Working with feature branches from TC docs should be helpful as well.
Hope that helps.
PS: Based on TC 2017.2.1 (build 50732)
What the difference in configs ?
Project with Branches Tab:
Project without Branches Tab:
If you only have one branch specified in the VCS config, you won't see a Branches tab.
TeamCity doesn't show branches in a project in case it knows nothing about them, i.e. there are no builds/changes in the project since project have been created. So if there is an old project with builds, newly created one has no knowledge regarding those builds. Try running a build in a branch, it should help.
I am working with Team City for .net and use it for continuous integration - works well. I have it running off my main branch.
I now have a release branch - how I can I configure to set up a release branch in team city. What is the best way to do this?
What I've done before is to copy the build configuration of my trunk build and then just create a new VCS root pointing at the other branch and use that in the new configuration.
Your can track several branches using Branch Specification field of VCS root. Specify wildcard for you branches like
+:refs/heads/release_* (for release branches) or
+:refs/heads/* (for all branches)
More details in docs.
Some notes:
Run build button runs it for default branch. Click ellipsis -> Changes tab to select specific branch.
Now you cannot use artifact dependencies for specific branch. Such dependencies will always use the default branch.
Regarding issues with artifact dependencies, it's not easy to create deployment configurations from branch specific artifacts. In this case I'd go using separate configurations for each branch. Otherwise you should rely on API and/or some artifact path name parsing logic.
If you don't need per branch deployments, it's completely ok to just use branch specs approach.
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.
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
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.
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.
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.
I'm dumb with continuous integration and noticed a behavior that does not seem right..
I'm using Mercurial with TeamCity. When I push changes the TeamCity detect the changes but don't run the build automatically. This is correct behavior? He should not detect the changes and run the build automatically?
Triggers are not added to build configurations by default in TeamCity. You'll need to go to the settings for the configuration and click on "Build Triggers" then "Add Trigger". The type of trigger I believe you are looking for is a "VCS Trigger".
The documentation for this feature can be found here.
I believe my issues was misunderstanding what was needed in Branch Filters. I thought I was supposed to enter the GIT refs I wanted to have builds triggered from
This wasn't working for me
+:refs/heads/*
-:refs/heads/releases/6.7.3
-:refs/heads/releases/6.8.30
-:refs/heads/releases/6.8.32
-:refs/heads/releases/6.8.34
And this is what finally figured out (I think) is that it is asking for the branch names inside TeamCity itself (the help text says "Newline-delimited set of rules in the form of +|-:logical branch name")
This worked for me, to trigger builds from the branch (GIT ref refs/heads/master for me, look back in your VCS Root setup) and all other branches except those labeled "releases/6.7.3", "releases/6.8.30", "releases/6.8.32" and "releases/6.8.34"
+:*
-:releases/6.7.3
-:releases/6.8.30
-:releases/6.8.32
-:releases/6.8.34