Child pages
  • Hajipur 9.1 EAP1 (build 35957) Release Notes
Skip to end of metadata
Go to start of metadata

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 directory 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:

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:

  • 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 runs an SSH agent with the selected uploaded SSH key during a build. When your build script runs an SSH client, it uses the SSH agent with the loaded key. You no longer need to manage SSH keys on the agent manually.

The first time you connect to a remote host, the 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 the 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:
  • or for an 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:

Other Improvements

  • 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)
  • The Run Custom Build dialog allows adding a build to favorites using the corresponding box on the Comments and Tags tab.
  • It is now possible to specify multiple VCS usernames for each level (default, VCS type or VCS root)
  • The default Subversion working copy format has been changed to 1.8
  • SSH Key support for Subversion checkout on agent TW-35092
  • Identify not-actual tests on the Investigations page TW-39494
  • logging preset selected on the Diagnostics page is preserved on server restart
  • fixed issues
  • No labels