Specifying TeamCity data directory on the TeamCity first start page

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/teamcity-startup.properties file.

If the TEAMCITY_DATA_PATH environment variable is specified, 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

Starting from this EAP, TeamCity allows storing the project configuration settings in a Subversion and Perforce version control repository. Previously, the only supported version controls were Git and Mercurial.

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:

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:

//depot/some/path/... => //team-city-agent/...

Administrator-defined ordering of projects and build configurations

By default, TeamCity displays projects, their subprojects, and build configurations on the Projects Overview page in the alphabetical order.
Starting from this EAP, project administrators can apply custom ordering to subprojects, and build configurations 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 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 hear 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 if a chain should be continued once some build in the chain finishes. However, the Finish Build Trigger is very limited. It does not allow specifying all the options we have for dependencies - tags, pin/unpin status, branch, etc. Also, it fires once the build finishes; 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 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 has got an ability to watch for builds in other build configurations and trigger a build if these builds change. The watched build is specified the same way as in the artifact dependency, with the same options.

The trigger above activates at 8:00 am MSK and checks whether a build in the BuildDist build configuration with 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:

SSH Agent build feature

This new build feature runs an SSH agent with selected uploaded SSH key during a build. When your build script runs an SSH client, it uses the SSH agent with loaded key. You no longer need to manage SSH keys on agent manually.

The first time you connect to a remote host SSH client asks if you want to add a remote host's fingerprint to the known hosts database at ~/.ssh/known_hosts. To avoid such prompts during a build you need to configure known hosts database beforehand. If you trust the hosts you are connecting to, you can disable known hosts checks either for all connections by adding something like this in ~/.ssh/config:

Host *
    StrictHostKeyChecking no

or for individual command by running an ssh client with the -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no options. You can find more information in the man pages for ssh, ssh-agent and ssh-add commands.

Server shutdown improvements

<TeamCity installation directory>/bin/teamcity-server.bat|sh scripts now support new options for stop command:

stop n
         Sends TeamCity server a stop command and waits up to n seconds for the process to end.
stop n -force
         Sends TeamCity server a stop command, waits up to n seconds for the process to end, kills the server process if it did not stop.

Other Improvements