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

Versioned Project Settings

Starting from this EAP, you can enable the two-way synchronization of your project settings with the version control. If synchronization is enabled, then:

  • each administrative change you make to the project settings in the TeamCity Web UI is committed to the version control
  • if you alter the settings in the version control, the TeamCity server will detect the modifications and apply them to the project on the fly.

Enabling synchronization for the project also enables it for all its subprojects. TeamCity synchronizes all changes to the project settings (including modifications of build configurations, templates, VCS roots, etc.) with the exception of SSH keys. The project settings are stored in the .teamcity folder in the repository.

(warning) Be aware that as soon as synchronization is enabled in a project, TeamCity will make one commit for this project and one for each of its subprojects to import the current settings. Enabling synchronization for a project with a large number of subprojects will generate a large number of commits.

You can enable synchronization on the Versioned Settings page of the project administration.

TeamCity will not only synchronize the settings, but will also automatically display changes to the project settings the same way it is done for regular changes in the version control. These changes are shown in all of the project build configurations automatically. As a side effect they can also trigger builds. If this is not desirable, a possible workaround is to attach settings VCS root to build configuration and exclude all of the changes with -:. checkout rule.

Known Limitations

  1. At the moment the only supported version control is Git.
  2. When running a history build in TeamCity, the current project settings will be used.
  3. (warning) Project settings may contain scrambled passwords. Once you enable settings synchronization, everyone who has developer role in the project will be able to see these passwords using changes diff.

Build Time Report

Similarly to Disk Usage, now you can see the comparative statistics of build time for projects and build configurations: the Build Time report is now available in the Project-related Settings of the TeamCity Administration area.

By default, the report displays total build duration within the last 24 hours for the server and individual projects with the percentage in relation to the parent project. The scope can be further drilled down to the build time of an individual build configuration:

The grouping and period settings can be modified.

Test Invocation Count

Starting from this version, we changed the way TeamCity works with a test which is run several times within a single build (for instance, this change affects TestNG tests with the invocation count > 1). Previously each test invocation was counted and shown as a separate test. For example, when you saw: Tests passed 1100, these counters included all invocations. Now, instead of 1100 tests you will see 1001 if one of the tests has been invoked 100 times, i.e. all invocations of the same test are counted as 1.

(warning) Consequently, you may see a reduced number of tests in some of your builds, which may affect the build status if the failure condition is set to "fail a build if the number of tests reduces".

Branch Filter for Notifications and Charts

You can now specify a branch filter in the notification rules to receive alerts only on the builds from the specified branches.
Besides, you can also filter statistic charts by branch.

Faster Backup / Restore

We have reworked storing data in tables, which should significantly speed up the backup and restore operations.

Clean Up Improvements

Clean-up settings for an individual project have been moved to the project settings; the general clean-up rules are still configured in the Administration area.
We changed the location of the build logs, so they are now placed in the build artifacts directory under .teamcity/logs directory. Besides build data unification this allows removing build logs using artifact cleanup rules, while leaving builds in the history. (warning) Note that backup / restore does not support new location of build logs yet.

We are also working on moving the clean-up operation to the background, and in this release you may notice that time when server is inaccessible because of clean-up is really small. Our goal is to remove this time completely in version 9.0.

Unicode Support for MS SQL and Oracle

The national character sets (nchar, nvarchar, nclob types) for text fields are now supported in MS SQL and Oracle databases used by TeamCity. You can now use Unicode characters in the following fields in TeamCity:

  • TeamCity user names (not logins)
  • VCS committers' names
  • VCS commit descriptions
  • file names
  • build status text
  • tags (on promotions and builds)
  • test names
  • mute and investigation comments
  • values of environment variables received from agents (in the agent types)
  • audit comments

Meta-Runner Upload

It is now easy to install a new meta-runner on your server: just upload the meta-runner XML definition file to a project where you want to use it.

Tagging Queued / Running Builds

TeamCity now provides an option of tagging queued builds. There are several ways of doing it:

Tags are now supported for running builds as well.

Other Improvements

  • The TeamCity plugin loader now supports plugin dependencies
  • Visual Studio Addin now supports Resharper 8.2 and dotCover 2.7
  • Server health reports checking build trigger configuration errors added
  • LDAP integration has a reworked error reporting which is now more likely to produce more specific and guiding error messages
  • fixed issues (\{Hajipur+9.0+EAP1+(31420)\}+tag%3A+-\{trunk+issue\}+-\{Gaya+8.1+%2829879%29\}+-\{Gaya+8.1.1+%2829939%29\}+-\{Gaya+8.1.2+%2829993%29\}+-\{Gaya+8.1.3+%2830101%29\}+-\{Gaya+8.1.4+%2830168%29\}+-Task+sort+by%3A+\{issue+id\}+asc)
  • No labels

1 Comment

  1. The known limitations section above could do with a warning about wiping out the project configuration when sync is first enabled: