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 significant CPU and memory resources. If these operations are moved to a separate process, chances are main TeamCity server will work faster.
- VCS worker improves reliability of the server. Any bugs in a VCS-specific component will affect the worker, not the server. If there is a memory or resources leak, it can cause VCS worker failure, but the server will at least be able to show the user interface, access builds, changes, etc.
- it should be easier to discover CPU and memory issues if they are related to VCS operations. Without the worker, if some VCS plugin eats a lot of resources it can be hard to find it, because the plugin runs in the same Java process as the (usually busy) server.
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, worker is not used for retrieving the source code from the repository - 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 remain as such even in version 8.0. So far we do not guarantee compatibility between server and worker - if you choose to install the VCS worker, most likely you'll need to upgrade it each time when you upgrade the 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.
With this EAP, project groups became one step closer. Now it is possible to:
- create sub-projects,
- move or copy a project to another project.
- Project hierarchy is shown in the Projects popup and in breadcrumbs, we also started working on displaying the hierarchy on the overview page
- Parameters defined in the parent project are available in sub-projects and their configurations, which effectively gives you an ability to define global parameters (TW-11202), as there is a Root project which includes all other projects
- VCS roots defined in the parent project are available in sub-projects, so we are planning to get rid of shared VCS roots and replace them with VCS roots attached to the Root project
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
Many people want to see changes from mercurial subrepos. Now they can by choosing an option "detect subrepo changes" in mercurial VCS root settings.
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 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
TW-287 is a pretty old request (submitted 6 years ago). Well, finally we've implemented it, so if you have some bad builds in the history, want to get rid of them and don't want to wait till next cleanup, now there is a way. There is a special permission for this operation, which is assigned to Project administrators role by default.
- ability to list build's artifacts via REST API