Now the build history clean-up is run as a background process, which means that now there is no server down-time and your TeamCity is available 24/7.
One thing should be noted though: if you are using the HSQL database, there is still a period of server unavailability when the HSQL database is being compacted. One more reason to switch to external database!
Starting from this EAP, you can configure a Perforce VCS Root to monitor Perforce streams (TW-20040). The work has just been started, but checkout on an agent and on the server are already supported.
. => <some dir>.
We continue improving settings synchronization with the version control in this EAP build:
The configuration of integration with issue trackers has moved to the project level, and now users with the Project Administrator permissions can access this feature in the Project Settings. The integration now is more enterprise friendly: if you have multiple projects on both the TeamCity and the issue tracker server or if you are using different issue-trackers for different projects, you will definitely benefit from this improvement.
Enabling integration for the project also enables it for all its subprojects; if the configuration settings are different in a subproject, its settings have priority over the project's settings.
TeamCity user interface has always been quite responsive. We are trying to avoid the whole page refresh as much as possible. As such we need some way to deliver events occurring on the server to browsers. For this we traditionally used HTTP polling. While being quite reliable, it still has disadvantages:
While responsiveness is a nice addition, a high server load is still a bigger problem. We attempted to solve these issues in this TeamCity EAP. Now it uses the WebSocket protocol for events, running builds updates and statistics counters (the number of builds in the queue, the number of agents, etc). Now every client establishes a single WebSocket connection with the TeamCity server, and the server pushes information about events to the browsers once they occur. Then it's up to the client code to decide what and how should be updated on the page.
The WebSocket connection is a new technology and comes with some limitations:
Previously TeamCity offered limited control over dependent build status if dependency fails. Now more options are available for more flexible configuration.
For each failed or failed to start dependency you can select one of the four options:
Previously TeamCity only supported integer numbers as statistics values. This caused problems with metrics like coverage or with custom values for percentage. For instance, if a statistic value changed by a fraction of a per cent, it was hard to configure a build failure condition to spot these little variations. Now TeamCity supports fractional numbers with up to 6 decimal points for all statistic values, finally eliminating this problem.
For quite a long time TeamCity inspections and duplicate code analysis tasks were available for IntelliJ IDEA and Maven projects only. Starting with this EAP you can now use Gradle projects as well.
TeamCity now supports configuration of Mercurial options per repository leaving behind the old approach which implied editing global mercurial configuration files on the server and agents. Now it is possible to enable some mercurial extensions only in the repositories where they are required.
<TeamCity installation directory>/binto
<TeamCity installation directory>/logs/memoryDumps/directory.