TeamCity 2021.1 EAP is open
Today we are opening the Early Access Program for TeamCity 2021.1!
TeamCity 2021.1 EAP1, code-named Morena, contains more than 70 improvements and fixes. In these release notes, we describe the most exciting updates.
Multinode setup improvements
Using external proxy as load balancer
To set up a high-availability TeamCity installation, the main server and secondary nodes need to be installed behind a reverse proxy. This proxy is responsible for routing requests to the main server while it is available and to the secondary ones when it is not. In addition to its default role, your proxy can now serve as a load balancer and manage communication between TeamCity agents and secondary nodes.
By default, an agent sends all its requests to the main node, and the main node redirects these requests to a suitable secondary node. If the main node becomes unavailable, the agent will not be able to communicate with its appointed secondary node. Its running builds will finish only when the main node becomes available again.
With the new load balancer approach, you can make this communication less dependent on the main server by routing agents to the proxy instead. Moreover, agents don’t need to be able to connect to the TeamCity nodes directly, which allows for more convenient configuration of your setup. For example, you can configure HTTPS only on the proxy level instead of setting it up on each secondary node.
See more details and the example proxy configuration in our EAP documentation.
Managing max number of builds on secondary node
If a secondary node is assigned to processing builds, it is now possible to limit the number of parallel builds it can run. This helps thoroughly manage servers’ hardware utilization and optimize your setup.
To configure it, go to Administration | Nodes Configuration, find the required node in the list, and click … next to its Processing data produced by running builds responsibility. The Builds distribution limits menu will open. In this menu, you can enter a relative limit of builds allowed to run on this node. We suggest that you set these limits depending on the node’s hardware capabilities.
If the maximum limit of allowed running builds is reached on all secondary nodes, TeamCity will be running new builds on the main node until some secondary node finishes its build.
Managing permissions of access tokens
You can now create access tokens with limited permissions for REST API requests. This gives you more control over how your scripts integrate with TeamCity. For example, if used in combination with the timeout setting, this feature allows generating short-lived tokens for specific tasks.
By default, the Permissions scope field’s value of a token is set to "Same as user", which means that the created token will grant the same permissions as those of the current user. You can use such token both for authentication via UI and for REST API requests.
If you change the value to "Limit to project", you will be able to limit the token’s access to a certain project and select particular permissions for it. The list of available projects and their permissions depend on your user permissions. Such token can only be used for REST API requests.
As some actions might depend on the availability of other actions, please make sure to carefully configure the token’s scope to get predictable results of your requests. In case of any issues, you can contact us via any convenient feedback channel.
Using Git shallow clones for faster builds on cloud agents
When setting up a Git VCS root, you can choose between different checkout policies depending on the lifecycle of your build agents.
If an agent is expected to be long-lived and run numerous builds, you may prefer keeping your project repository mirror right on this agent — to speed up the successive builds and to have quick access to the whole history of revisions. If an agent is short-lived (for example, a disposable cloud agent) and your builds do not require accessing the change history, TeamCity can now use the Shallow clone option to fetch a single revision. For a big repository, this can make the build start significantly faster. You can also let TeamCity select the approach automatically, based on the agent configuration and the presence of the mirror on it. See more details in our EAP documentation.
Viewing thread dump of process running inside Docker container
TeamCity allows viewing a thread dump of processes running on a build agent machine right on the Build Results page. Now, you can view it even if the process runs inside a Docker container (for example, with our Docker Wrapper or Docker Compose functionality). This works for Java processes inside Windows containers and for all processes inside Linux containers.
In the build’s Overview click View thread dump:
The preview shows the structured information about your processes:
Python runner updates
- The Python build runner now supports the Venv virtual environment tool.
- The runner can automatically install the following missing tools on the build agent: Flake8, Pylint, Pytest.
Setting .NET SDK requirements for build agents
The .NET build runner now allows you to specify a requirement to SDKs installed on a build agent. You can enter the list of expected SDK versions when configuring a .NET step, and TeamCity will automatically create agent requirements: the current build will only run on agents that have all the required SDKs.
For example, this build will run on an agent only if .NET 5.0 and .NET 4.8 are installed on it:
See all resolved issues.
More features are on their way – stay tuned and check our roadmap for details.
Download TeamCity Morena 2021.1 EAP1 or pull the Docker image with the
EAP tag. Remember to install it on a trial server as the new version changes the TeamCity data format and downgrading to the previous production version is not supported.
All our EAP releases come with a 60-day Enterprise evaluation license for an unlimited number of agents and build configurations.