VCS worker (experimental)
VCS worker is a separate service responsible for communication with VCS repositories. The service was extracted from TeamCity core and can now be installed on any machine on your network. TeamCity server can be configured to use one or more VCS workers, in which case all VCS specific tasks will be routed to appropriate workers. For example, it is possible to route all Git specific requests to one worker, and Subversion requests to another.
VCS worker is disabled by default and TeamCity behaves as usual, i.e. performs all VCS operations from the main server process.
With large setups VCS worker(s) installed on separate machine should decrease TeamCity server load significantly. Please refer to our documentation for instructions on configuring TeamCity in conjunction with VCS worker: http://confluence.jetbrains.com/display/TCD8/VCS+worker+installation.
Note that the feature is still experimental and is subject to change. For now, we do not preserve backward compatibility, which means that new server versions might not be compatible with earlier versions of VCS worker.
Ability to create sub-projects, move project under another project, inherit parameters.
Server health reports
New page was added in Administration area: Server health. Our intention is to provide server administrators with different reports highlighting possible configuration problems. Currently the following reports are available:
- Database related problems
- Redundant (duplicate) VCS roots
- Unused VCS roots
- VCS settings that increase the probability of clean checkout
- Critical errors in configuration files
- and others
Disk usage report
Have you ever tried to figure out which project artifacts consumed most of disk space on the server? If so, then you'll appreciate this feature. It shows you the size of artifacts and build logs in each project and configuration, allowing to find hot spots easily.
Queued build page
Build queue is a kind of shadow world of TeamCity. While build stays in the queue, there is no easy way to overview its parameters, changes, dependencies and so on. Internally, a queued build does not differ much from a regular build, so we thought it would be nice to show its details in almost the same way. Now you can click the #number link in the build queue and you'll be redirected to the queued build page with all the familiar tabs:
- Compatible agents
Our plan is to improve dependencies presentation on this page, and to simplify discovery of state and progress of the current build chain.
Sub-repositories support for Mercurial
Shared resources improvements
We continue improving the shared resources feature. In this EAP we added one more type of resource: resource with custom values. You can now define a resource with several values like this:
You can then add a lock for such a resource by adding the "Shared resources" build feature to a build configuration. The lock can be added to any available value, all values or a specific value. In case of any or specific value, TeamCity will start a build only if the value is available (i.e. no other builds obtained locks for this value). Actual value will become available as a parameter, so you can even use it in the build script. If a lock for all values is selected, TeamCity will start a build only when all values become available. Essentially, this works like a pool of resources – until there are values in the pool, builds can start, once all values are taken, builds will be put on hold.
Investigation and mute for build problems
.NET Inspections improvements
Full MSBuild model support
We've worked hard for a couple of months with our colleagues from the ReSharper team to fix a large set of bugs in server-side .NET code analysis. Generally, all those bugs could be described as "There are no errors (warnings) in Visual Studio, but TeamCity shows a number of problems in my code."
The reason was that the project model which is an input for code analysis was incorrectly constructed outside of Visual Studio. In order to fix this, we now support all of MSBuild-related features usually used by developers.
Some of them are:
- MSBuild properties usages in project files (TW-19854, TW-20837, TW-23892, TW-25898)
- Auto-generated code usages (TW-19220, TW-24921)
There still might be some issues so we are highly insterested in your feedback about this feature!
Analysis results caches
We have also received issue reports about poor performance of code analysis on the server (compared to ReSharper). To mitigate this, all data produced by code analysis which could be reused in future builds on the same build agent is stored outside of the checkout directory (by default) and is cleaned up together with other agent caches.
Remove build feature
- ability to list build's artifacts via REST API