What's New in TeamCity 2022.10
Before this version, setting up HTTPS on a TeamCity server has been one of the challenging tasks for a server administrator. It required the knowledge of the TeamCity server configuration and experience in configuring proxy servers. Now enabling HTTPS access to TeamCity is easy: after you launch your TeamCity server, all you need to do is upload an HTTPS certificate, or a certificate chain in the PEM format to the server, and TeamCity will do the rest.
These settings will affect the built-in Tomcat server configuration. If your TeamCity server is behind a proxy, configure HTTPS on the proxy side.
Read this article for details.
The Sakura UI is now enabled by default for all new TeamCity users. This fresh, modern interface created with web accessibility in mind is constantly evolving: we have reduced visual complexity of the classic UI, improved the UI performance, and provided easier access to essential features.
The Sakura UI boasts of feature parity with the classic TeamCity UI and offers unique features, such as a convenient sidebar, the trends view for projects, and builds comparison page.
The Sakura UI is making its way into the Administration area. Creating new build steps is more user-friendly now with the flat list of available build runners.
Refer to this article for details.
This TeamCity version supports Amazon Web Services (AWS) connection. It allows defining AWS credentials once and using them in builds via the AWS Credentials build feature. You can use different AWS credential types: access keys, IAM Role, and the Default credential provider chain.
You can launch an interactive browser-based shell directly from the TeamCity UI. The shell helps you investigate agent-related issues and works for EC2 agents with preinstalled AWS Systems Manager Agent (SSM Agent).
Read this article for details.
Before this version, investigating issues on cloud agents was difficult, as the agent could become unavailable in the middle of the investigation process when its termination condition was met. Now you can disable a cloud agent for maintenance. In maintenance mode, you can log in to the agent, view its log, and perform other operations. The cloud agent will not be stopped according to the termination conditions and will be unavailable for builds unless assigned to a build explicitly.
We have made changes to the Kotlin DSL documentation: altered the design and adjusted the layout for better readability. Most importantly, we provided meaningful examples to improve the experience for developers who want to create projects and build configurations in TeamCity programmatically.
You can sign in to TeamCity with a Google account. Before enabling this module, you need to configure a Google connection in the Root project's settings.
If you have a connection to a Bitbucket Cloud, GitLab, and Azure DevOps VCS Root configured in TeamCity, you no longer need to enter your password when creating new entities (projects, build configurations, or VCS Roots) via this connection. Refresh tokens are now enabled by default for these VCS Roots. Such tokens are short-lived providing more security than passwords or personal access tokens: the TeamCity server refreshes them automatically without sharing any related data with agents.
You can now use access tokens with limited permissions not only for REST API requests, but also for basic authentication and for logging in via the UI.
Now TeamCity supports large artifacts (over 4 GB) out of the box. No additional configuration is needed to publish and download zip archives of large artifacts.
Project Administrators now have a new permission allowing them to change a user's VCS username in the project without adding the permission to modify user profile and roles. The permission will be present for this role in the new TeamCity installations; for existing installations it has to be added manually.
You can now promote a personal build. After promotion, TeamCity will try to run the promoted build and all its dependencies as personal builds unless the check out settings for any of the dependencies differ.
In TeamCity 2022.10, you can use new REST API requests to check the status of your nodes in the high availability setup and reassign node responsibilities. See this section for details.
If stream support is enabled in a Perforce VCS Root, the Perforce Shelve Trigger will now automatically detect the target stream from the changed files and trigger a personal build in this stream.
Autodetection of the branch works in the run custom build dialog even if the default branch is specified.
The same applies to the REST API endpoint. You do not have to specify the stream explicitly there, but can be specified via the desiredStream HTTP parameter.
Autodetection also works in the REST API when the
desiredBranch parameteris not set in an HTTP request.
After you run a build with Commit Status Publisher on a changelist that has a review in Helix Swarm, TeamCity shows the Swarm Reviews section on the build overview page. From each change, you can navigate to the change page on the Helix Swarm using Open in Helix Swarm.
Before upgrading, we highly recommend reading about important changes in version 2022.10 compared to 2022.04.x.
See the TeamCity roadmap to learn about future updates.