Child pages
  • Hajipur 9.1 EAP1 (build 35957) Release Notes

Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


Specifying TeamCity data directory on the TeamCity first start page

Configuration The configuration of TeamCity data directory has been moved from the installation wizard to the TeamCity startup screens. We hope it will improve the first time installation experience on non-Windows platforms.
The TeamCity data directory path specified on startup screens will be stored in the <TeamCity installation directory>/conf/ file.

If environment variable the TEAMCITY_DATA_PATH environment variable is specified, then for compatibility reasons, the value of this variable will be used as the path to the data directory for compatibility reasons.

Versioned project settings in Subversion and Perforce


By default, the settings are stored in the .teamcity in the root of the repository. If you wish to change the path used by TeamCity, you can create a special VCS Root dedicated to the VCS settings storage, and specify the path as you want there.

Note that if the settings are changed via the user interface, a commit in the VCS will be performed on behalf of the user specified in the VCS root. However, the commit message will also contain the username of the TeamCity user who actually made the change via the UI change:

Hide If

For example, in case with Perforce TeamCity will use the .teamcity directory relative to the client you configured; e.g. to store the settings in //depot/some/path/.teamcity folder, specify the Perforce mapping as follows:


By default, TeamCity displays projects, their subprojects, and build configurations on the Projects Overview page in the alphabetical order.
Currently each user can define the order to their liking on the Overview page using the up-down button on the Configure Visible Projects pop-up. However, a unified approach might be needed for a team, and now Starting from this EAP, project administrators can apply custom ordering : you can now reorder to subprojects, build configurations, and templates of a project on the Project Settings page and use it as the default one for all the team members, thus saving them the effort of defining the order manually. Individual users can still manually tweak the display using the up-down button on the Configure Visible Projects pop-up, but hopefully will need to do it less frequently now.

Create build configuration from URL

In addition to creating a project from URL, TeamСity now comes with an option to create a build configuration from a VCS URL. All you need to do is enter a VCS URL in the create configuration wizard, select default options to create a build configurations configuration and that's it!

Schedule trigger improvements

TeamCity has different triggers suitable for various use cases. While many use cases are already covered, we still we hear more and more complains about other complaints about a number of scenarios which are hard to automate. This is especially true for scenarios when a build chain should be continued automatically based on some event. Traditionally, we recommend using the Finish build trigger Build Trigger if a chain should be continued once some build in the chain finishes. However, the Finish build trigger Build Trigger is very limited. It does not allow to specify specifying all the same options which we have for dependencies - tags, pin/unpin status, branch, etc. Also, it fires once the build finishes, however ; but in many scenarios this is undesirable. Instead, it would be better to wait for some time before continuing the chain, or continue the chain only once or twice a day.

Since the Schedule trigger Trigger already has a notion of time, it seemed more appropriate to extend this trigger instead of adding new options to the Finish Build trigger. In this EAP build, the Schedule trigger Trigger has got an ability to watch for builds in other build configurations and trigger a build if these builds change. The watched build is defined specified the same way as in the artifact dependency, with all the same options.

The trigger above activates at 8:00 am MSK and checks whether a build in the BuildDist build configuration with tag the "bs-deploy" tag has changed. And if it changed, the trigger will put a build in the queue. Note that a build of BuildDist will be promoted to a triggered build if there is an artifact or snapshot dependency on BuildDist in the configuration where the trigger is defined.

New options should cover the following feature requests:

  • TW-4799 - option for scheduled trigger to do not run a build if artifact-dependency build has failed
  • TW-11553 - option to trigger a build when artifact it depends on changes
  • TW-14975 - option in schedule trigger to run a build with changes corresponding to last successful snapshot dependency build

SSH Agent build feature

This new build feature allows accessing an uploaded SSH key on an agent during a build.

Server shutdown improvements


  • UI improvements including the chains page
  • Merged MSTest & VSTest plugins (in progress)
  • Support for multiple VCS usernames (in progress))
  • Support for Maven 3.3.1
  • Support for Gradle 2.4
  • Support for Visual Studio 2015 and Microsoft Build Tools 2015 preview in MSBuild and Visual Studio Solution runners, as well as MSTest 2015 (14.0), VSTest 2015 (14.0)(question)
  • The default Subversion working copy format has been changed to 1.8
  • logging preset selected on the Diagnostics page is preserved on server restart
  • fixed issues