Child pages
  • Lakhnau 2020.1 EAP1 (build 77859) Release Notes
Skip to end of metadata
Go to start of metadata

On this page:

Bundled Kubernetes plugin

Since this EAP, we are bundling the Kubernetes plugin with TeamCity. The plugin allows running TeamCity cloud agents in a Kubernetes cluster and implements the Helm build runner.

The plugin implements a new type of cloud profile so you can add your Kubernetes cloud images to this profile.
Depending on the pod specification selected for a Kubernetes image, you can configure specific settings or, for example, use a pod template. As for any other cloud image in TeamCity, you also need to choose an agent pool and, optionally, enter an agent name prefix and a maximum number of allowed instances of this image.

Pull requests support for Azure DevOps

Now, your TeamCity builds can detect pull requests in Azure DevOps Services and Server (2018 or later).

To configure this build feature for a build configuration, go to Build Configuration Settings | Build Features, click Add build feature, and choose Pull Requests. Select the Azure DevOps hosting type and enter a token to access your repository.

Note that in the case with Azure DevOps TeamCity detects requests on a merge branch – not on the pull request itself as in other VCS, thus your builds will contain both the commit with changes and the virtual merge commit.

Processing build triggers on secondary nodes

With each release, we make more features of the main server available to secondary servers. This ensures high availability and optimizes the usage of resources in your TeamCity setup.
In setups with many build agents, a significant amount of the main server’s CPU is allocated to constant processing of build triggers. By enabling this responsibility for one or more secondary nodes, you distribute the trigger processing tasks and necessary CPU load between the main node and the responsible secondary ones.

To assign the responsibility to a secondary node, go to and select the "Processing build triggers" option opposite one or more nodes.

Experimental UI: Viewing all agents

We continue improving the experimental Agents page: this time, we are introducing the All Agents view that displays the most important information on all agents. This view is helpful when you have a moderate number of agents and want to quickly preview their states and manage them side by side, on a single dashboard.

Copying secure values for tokens from other projects

When you create a project from DSL, TeamCity now automatically looks for missing secure values of the project's tokens in other projects.

If you generate tokens for a DSL-based project in TeamCity, these tokens are saved in the project's DSL in the VCS while their respective secure values are stored in the TeamCity system settings. When you create a new TeamCity project based on the same DSL, you have to make sure that secure values, corresponding to these tokens, are specified in this new project as well.

On the Project Settings | Versioned Settings | Tokens tab, you can enter the required secure values manually but, if TeamCity finds the same tokens in other projects you are permitted to edit, you will also have an option to copy the values used in these projects.

If there is one or more secure values available for a token, the  button will appear opposite this token. Click it to review available projects and choose a project to copy a value from, and then click Copy to confirm your choice.

Notes on limitation of CORS support for writing operations

TeamCity improves the security of REST API integration mechanisms by introducing CSRF tokens. This change will not affect the behavior of custom integration scripts unless they rely on Cross-Origin Resource Sharing (CORS) in writing operations and the internal property is enabled in TeamCity (it is disabled by default).

Previously, CSRF protection was presented in TeamCity with the verification of Origin/Referer headers of HTTP requests. To improve TeamCity CSRF protection, this method was disabled in favor of a more secure one – CSRF tokens. Since this EAP, TeamCity stops supporting the CORS mechanism for POST/PUT/DELETE REST API requests. Cross-origin GET requests’ headers are processed as before and still require CORS configuration.

If necessary, you can enforce verification of Origin/Referer headers for writing CORS operations by setting the teamcity.csrf.paranoid=false internal property. Note that this is a transitory and less secure solution: we strongly recommend refactoring your existing requests so they comply with the new security policy and provide a token within a CSRF header or parameter. A CSRF token can be obtained via the GET https://your-server/authenticationTest.html?csrf request and provided via the X-TC-CSRF-Token HTTP header to the write CORS requests.

See all fixed issues.

  • No labels