Child pages
  • Jaipur 2018.1 (build 57985) EAP2 Release Notes
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 32 Next »


See also Jaipur 2018.1 (build 57605) EAP1 Release Notes

Read-Only Node

TeamCity makes a step towards High Availability by introducing a read-only mode for a server. It is currently possible to start a second, read-only TeamCity server looking at the same database and data directory as the main one. 
The read-only server allows users read operations: view the build information, download artifacts, etc. during the downtime of the main server, e.g. during upgrade.

Starting Read-Only Node

A Read-Only node uses the same Data Directory and the same external database as the main TeamCity Server. Therefore, a prerequisite of using the Read-Only node is to ensure that it has access to the data directory and database of the main TeamCity Server.

In addition to the data directory shared with the main server, the Read-Only node requires a 'local' data directory where it stores some caches, unpacked external plugins and some other configuration. By default, the 'local' data directory is automatically created under the <Main Data Directory>/nodes/read_only_node path during the first start. You can override its location using property in the TeamCity start-up scripts.

To start a Read-Only node alongside the main TeamCity Server, do the following:

    1. Install the TeamCity software as usual: download a distribution package, unpack it or follow the installation wizard.
    2. Configure the TEAMCITY_DATA_PATH environment variable on the Read-Only node, make sure it points to the shared data directory.
    3. Add additional arguments to the TEAMCITY_SERVER_OPTS environment variable: TEAMCITY_SERVER_OPTS=-Dteamcity.server.role=read-only-server

High-Availability Installation

Using a read-only node, it's possible to setup High-Availability TeamCity installation, that will have zero read downtime, i.e. when the main server is unavailable or is performing an upgrade, requests may be routed to the read-only node. Such setup requires installing both the main server and the read-only node behind a reverse proxy, that should be configured to proxy requests to the main server while it's available and to the read-only in other cases.

For example, the following NGINX configuration will route requests to the read-only node only when the main server is not available or when the main server responds with 500 or 503 status codes, which generally means that it is starting or is performing an upgrade.  

If you did not setup TeamCity server behind reverse proxy before, make sure to review our notes on this topic.


  • Not all the pages in the Administration area are available in the read-only mode. For example, Projects Import tab is not shown as it's not useful when the server can't perform write operations.

  • Currently, only bundled and a limited set of some other plugins are loaded by the read only server, so some functionality provided by external plugins can be missing.  

  • Currently, it's not possible to switch the read-only node to the write mode. So in case of the main server failure, a new main server should be started.

  • Users may need to re-login when they are routed to the read-only node if they didn't use Remember Me.

User Interface Changes

We continue updating the interface:

  • new build row presentation, featuring the artifacts icon has been added to overview and favorite builds pages
  • build configuration home page has been redesigned (besides, internally it now uses REST API to show its data)

Trusted HTTPS Certificates

TeamCity now allows uploading a so-called trusted HTTPS certificate - this could be a self-signed certificate, or a certificate signed by a not well-known certificate authority (CA). After that, this certificate becomes trusted by TeamCity, which means TeamCity will be able to open HTTPS connections to a resource with this certificate. Previously, to allow such connections, the certificate had to be imported into Java used by the TeamCity server with help of the keytool utility.

In the final 2018.1 version these trusted certificates will be delivered to agents automatically.

Currently trusted certificates storage is global for the whole server and affects all of the server projects. To upload a trusted certificate, navigate to the Root project administration area and select Trused SSL Certificates menu item in sidebar.

Project Level NuGet Feed

In previous versions of TeamCity NuGet feed was global for the whole server. Not only that, but once the feed was enabled, TeamCity started indexing of all of the .nupkg files published as artifacts. On a large server this can lead to a really large feed, delays with packages appearance, increased disk usage for the feed metadata and sometimes terrible performance which was one of the most common complaints in the past.

Starting with this EAP, it is finally possible to enable a NuGet feed at the project level, which means each project can have its own NuGet feed. By default, TeamCity no longer adds all .nupkg artifacts to the project feed; instead, you can add "NuGet packages indexer" build feature to build configurations whose artifacts should be indexed. If you prefer to have a single feed for the whole server, you can enable it at the Root project level and add  the packages indexer build feature to build configurations which produce relevant packages.

If you don't want to add dedicated build features to build configurations for some reason, then you can still enable automatic packages indexing on the project NuGet Feed page. In this case, as it was before, all of the .nupkg artifacts produced by this project will be indexed automatically.

Besides, .nupkg files indexing is now performed by the agent itself as one of the final stages of the build.


Note that starting from this version the following NuGet-feed-related parameters are deprecated:

  • teamcity.nuget.feed.auth.server
  • teamcity.nuget.feed.server
  • system.teamcity.nuget.feed.auth.serverRootUrlBased.server


Docker Support

  • Docker wrapper now supports .NET CLI and PowerShell runners, which means you can easily run these steps in a Docker container.
  • Docker Build runner has been replaced with Docker Command runner with support for build, push and some other docker commands

Bundled Amazon S3 Support

TeamCity now comes bundled with Amazon S3 plugin, which allows uploading to, downloading and removing artifacts from S3. Resolution of artifact dependencies as well as clean-up of artifacts is handled by the plugin. The artifacts located externally are displayed in the TeamCity web UI.

Viewing Shared Resources Usage

Starting from this build, if at least one resource lock is defined in a build configuration, you can view the resources used by the build on the Shared Resources tab of the Build Results page. The tab displays the resources and their type, including the locks used by the build for each resource.

Clicking the resource name takes you back to the the shared resources configuration page on the project level.

Other Improvements

  • Now it is possible to use parameter references in agent requirement settings 
  • Users can now hide health report items if they are not relevant for their project (previously only sysadmins could hide them) 
  • The bundled JetBrains .NET Tools have been updated to the latest released versions: dotCover 2018.1 and ReSharper CLT 2018.1 

  • The bundled Ant has been updated to version 1.9.11

  • The VSS (Visual SourceSafe) plugin has been un-bundled

  • All fixed issues 






  • No labels