Feature branches support has got significant improvements in this EAP build. Now you can configure right in VCS root what branches you want to monitor in a build configurations.
The syntax of branch names specification is similar to checkout rules:
Note that only one * is allowed. Everything that is matched by wildcard will be shown as a branch name in TeamCity interface. For example,
+:refs/heads/* will match
refs/heads/feature1 branch but in TeamCity interface you'll see
feature1 only as a branch name.
Once you're done with branch specification, TeamCity will start to monitor these branches for changes. If your build configuration has VCS trigger and a change is found in some branch, TeamCity will trigger a build in this branch.
You'll also be able to filter history, change log, pending changes and issue log by branch name. Also branch names will appear in custom build dialog, so you'll be able to manually trigger a custom build on a branch too.
But that is just a tip of an iceberg. Let's dig a little bit deeper.
Branch specification & default branch
The branches field is only available for two version control systems: Git & Mercurial.
In VCS root settings for these systems there are fields "Ref name" (Git) and "Branch name" (Mercurial). They define a so-called default branch. Default branch is used in situations when branch name was not specified. For example, if someone clicks on a Run button TeamCity will create build in default branch.
Build from a branch is marked with a special label:
You can also filter history by a branch name if you're interested in a specific branch only.
Builds from default branch won't get any labels.
As you know for each build TeamCity shows changes included in it. For builds from branches changes calculation process takes branch into account and presents you with changes relevant to the build branch. Changelog with it's graph of commits will help you understand what is going on in the monitored branches.
TeamCity tries to detect new failing tests in a build, and for those tests which are not new, you can see in which build the test started to fail. This functionality is aware of branches too, i.e. when the first build is calculated TeamCity traverses builds from the same branch.
Additionally, branch filter is available on test details page. So you can see a history of test passes or failures in a single branch.
VCS trigger is fully aware of branches and will trigger build once a check-in is detected in a branch. All VCS trigger options like, per-checkin triggering, quiet period, triggering rules are directly available for builds from branches too.
If build configuration with branches has snapshot dependencies on other build configurations, when a build in a branch is triggered, all builds from the chain will be marked with this branch too.
It is currently not possible to configure artifact dependencies to retrieve artifacts from a build from a specific branch, artifact dependencies always use builds from default branch. The same applies to finish build trigger. It will only watch for finished builds from default branch.
All notification rules except "My changes" will only notify for builds from default branch. At the same time "My changes" rule will work for builds from all available branches.
Build configuration status
Build configuration status is calculated based on builds from default branch only. Consequently per-configuration investigation works for builds from default branch. For example, successful build from non-default branch won't remove per-configuration investigation. But successful build from default branch will.
Multiple VCS roots
ChangeLog, pending and build changes pages unification
Pending and build changes views have been transformed to look similar to change log.
Artifact dependency changes
Mark build as successful / failed
- XCode runner is now bundled with TeamCity
- NuGet 1.8 / 2.0 support