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 in the network. TeamCity server can be configured to use one or more VCS workers, in which case some or 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.
There is a number of situations when VCS worker can be useful:
- it can improve responsiveness of the TeamCity server, as VCS specific operations sometime require CPU power and significant amounts of memory. If these operations are moved to separate process, chances are main TeamCity server will work faster.
- VCS worker improves reliability of the server. Any bugs in VCS specific component will affect VCS worker but won't affect server. If there is a memory or resources leak, it can cause VCS worker failure, but server at least will be able to show user interface, access builds, changes, etc.
- it should be easier to discover CPU and memory issues if they are related to VCS operations. Without worker if some VCS plugin ate a lot of resources it can be hard to find it, because plugin works in the same Java process as server and server usually does a lot of work. With worker this should be easier.
Currently worker supports the following operations:
- changes collecting for a VCS root
- retrieving of file content
- patch construction for agent in server side checkout mode
- source code labeling / tagging
- supported VCS plugins: Perforce, TFS, Subversion, Git, and Mercurial
Note that in case of agent side checkout when agent retrieves source code from the repository worker is not used, agents themselves will connect to VCS repository as usual.
In general this component can be useful for large setups as it gives server administrators more flexibility for tasks like server monitoring and scalability.
The feature is in experimental state and can be left in this state even in version 8.0. So far we do not guarantee compatibility between server and worker, if you choose to install worker, most likely you'll need to upgrade it each time when you upgrade server. Also there is no auto-upgrade procedure yet.
If you want to experiment with this feature please refer to our documentation for VCS worker installation instructions: http://confluence.jetbrains.com/display/TCD8/VCS+worker+installation.
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