Both the main TeamCity server and build messages processor can be started / stopped using regular TeamCity scripts (
teamcity-server.bat, teamcity-server.sh) or Windows services.
The build messages processor uses the same approach to logging as the main server. You can check how the startup is doing in the <TeamCity installation directory>/logs/teamcity-server.log file. You can also open <processor URL> in your browser, there you should see regular TeamCity startup screens.
Enabling Build Messages Processor
The TeamCity cleanup task runs on the main TeamCity server only. In a two-node configuration as well as in a single node configuration, it can work at the same time while the servers are handing handling data from the running builds.
In new installations, these project-related permissions are added to the Project Administrator role. After upgrade, no permissions changes are applied, but you might want to review the permissions, e.g. consider removing the Agent Manager role inclusion from the Project Administrator role and adding the above-mentioned permissions to Project Administrator role manually.
Administration | Tools page improvements
In previous versions of TeamCity you could install a couple of predefined tools to TeamCity agents via the Administration | Tools page. In addition to that you could manually distribute zip archives to agents if you place them into special place on disk.
In addition, some of the plugins, like NuGet had own place for uploading new versions to agents.
In this EAP we unified all these tasks under the single interface. Now, you can manage NuGet versions, install recent version of ReSharper command line tools, or upload an arbitrary tool in a zip archive - all from the same Administration | Tools page.
Flaky Test Detection
TeamCity now supports flaky test detection. A flaky test is a test that is unstable (can exhibit both a passing and a failing result) with the same code.
Flaky test detection is based on the following heuristics:
- It is possible now to get help on locator usage by sending a request with "$help" string as a locator
- Project features are now exposed
- Order of projects and build configurations can now be changed via via via .../app/rest/projects/xxx/order/projects and .../app/rest/projects/xxx/order/buildTypes requests
- It is now possible to get and update TeamCity license keys
- Maximum number of agents in an agent pool is supported
Maven-related operations performed on the server-side are now moved to separate process
New option added to Subversion VCS root: Enable non-trusted SSL certificate; if this option is enabled, TeamCity will be able to connect to SVN servers without properly signed SSL certificate
Starting from this EAP TeamCity uses unidirectional agent-to-server connection via the polling protocol by default. If for some reason the polling protocol cannot be used, TeamCity switches to the fallback bidirectional communication via xml-rpc.
the bundled IntelliJ IDEA is updated to 2016.2 RC (162.1121.10)