h2. Feature branches

Feature branches support has got significant improvements in this EAP build. Now you can configure what branches you want to monitor in a build configurations right in the VCS root.
The syntax of branch names specification is similar to checkout rules:

Note that only one {{\*}} is allowed. Everything that is matched by the 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.

h4. 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.

Note that parameter references are allowed in branch specification as well.

h4. Builds

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.

h4. Changes

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.

h4. Tests

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.

h4. Triggers

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.

h4. Dependencies

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.

h4. Notifications

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.

h4. 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.

h4. Multiple VCS roots


h4. REST
Preliminary support for exposing branches is added.
The following requests are supported:
All available branches of a build configuration: GET {{http://teamcity:8111/app/rest/buildTypes/<buildType_locator>/branches}}
Build locator now supports "branch" dimension. Use "any" for <branch_name> to return builds from any branch, if branch is not specified, only builds from default branch are returned
e.g. all builds for the specified branch: GET{{http://teamcity:8111/app/rest/builds/?locator=branch:<branch_name>}}
get build's branch: GET {{http://teamcity:8111/app/rest/build/branch}} - returns text-plain response with branch name, empty string for default branch

h2. Change Log, pending and build changes pages unification

Pending and build changes views have been transformed to look similar to change log. We also added new option "Show files" to easily expand all changes on the current page and show affected files. As you can see graph of commits is now available on build changes as well:


h2. Artifact dependency changes

In previous EAP we started to show changed artifact dependencies in changes popup. We worked on this feature a bit more and added it in all other places where changes are shown: build changes and change log.


h2. Mark build as successful / failed

Sometimes you need to mark a failed build as successful, for example, if a failure happened because of a minor problem, and you want other builds to take artifacts of this build, or your want to promote this build further by pipeline.
On the other hand, there are cases when TeamCity was not able to determine build failure. For example, build finished successfully but because of an error in build script it did not produce any artifacts. So the build clearly cannot be treated as successful.

To handle both of these cases we added ability to mark build as successful or failed. In both cases you need to provide some description of the reason of this operation. Also to be able to change build status one must have *Project administrator* role. These operations are logged into audit log and can be examined later.

h2. Build steps execution

Build step execution policies introduced in the previous EAP have been improved. Now you have a choice of the following policies:
Execute step if:
* Only if all previous steps were successful (default choice, this is how previous versions of TeamCity behaved)
* Even if some previous steps are failed
* Always, even if build stop command was issued

The last policy can be useful for some cleanup tasks. Note that as in previous TeamCity version whether the step is failed or not in most of the cases is determined by process exit code.

h2. NuGet support improvements

We added support of NuGet 1.8/2.0. Now you may even upload your own NuGet.CommandLine package instead of downloading it from the public feed.

We work hard to improve NuGet Trigger. Major bugs were fixed, more robust error reporting was added. Starting from now, NuGet Trigger supports Prerelease packages. 

We improved NuGet Installer runner. It no longer requires you to have {{packages/repository.config}} file under solution. Starting from this release, NuGet Installer uses Visual Studio solution file (.sln) to create the full list of NuGet packages to install. It also supports Solution-Wide packages, from {{.NuGet/packages.config}} file. We added an option on how packages upgrade is done. Now you may select to update packages for entire solution of per packages.config files.

h2. Other

* Added support of Microsoft Team Foundation Server (TFS) 2012 version control
* [XCode runner|TW:Xcode Runner] got lots of improvements and is now bundled with TeamCity
* Eclipse Juno (4.2) support. Dropped support of Eclipse older than 3.4.2
* Ruby environment configurator: Autocreate rvm gemset if it not exists
* Rake runner: Specify additional interpreter parameters. Useful with JRuby JVM parameters
* Cloud support improvements
* Agent requirements imposed by parameter references now provide details where in configuration the reference is defined
* [fixed issues|http://youtrack.jetbrains.com/releaseNotes/TW?q=%23fixed+Fix+versions%3A+{Faradi+7.1+EAP+%2823732%29}+sort+by%3A+Priority+-Task+-{trunk+issue}&title=Faradi+7.1+EAP+%2823732%29]