What's New in TeamCity 2023.05

Version 2023.05 introduces a new requests distribution logic that spreads the load more effectively between TeamCity nodes and minimizes the number of negatively affected users when a node is down due to a planned maintenance or an unexpected failover.

This new logic is based on sending new requests to a random node that has the Handling UI actions and load balancing user requests responsibility. After this initial draw, TeamCity memorizes which node was selected and relegates subsequent requests to the same node.

Learn more: Round-Robin.

Prior to version 2023.05, the "VCS repositories polling" responsibility (allows nodes to poll repositories for new commits and detect changes) was available for a single node in the entire cluster. Starting with this version, you can assign this responsibility to multiple nodes. This enhancement allows you to evenly distribute the load across nodes and reduce the delay before triggering new builds.

To specify which node should handle your current requests (for instance, adding a new build to the build queue), use the node selector in the bottom right corner of the TeamCity UI. The currently selected node is marked with the star icon on the Nodes Configuration page.

Learn more: VCS Repositories Polling.

Previously, the main TeamCity node automatically re-gained the "Processing data produced by running builds", "VCS repositories polling", and "Processing build triggers" responsibilities when a TeamCity cluster had no nodes with such responsibilities. In addition, when you switched the "Main TeamCity node" responsibility to another node, this new node automatically inherited all other responsibilities.

Starting with version 2023.05, main nodes do not automatically accept "missing" responsibilities. This change grants you more control over main nodes and allows you to reduce their load and CPU/memory consumption. The only main node responsibilities you cannot disable in TeamCity UI are "Main TeamCity node" (you can clear this checkbox only by enabling this responsibility on another node) and "Handling UI actions and load balancing user requests".

You can now create backups on any node with the Handling UI actions and load balancing user requests responsibility.

Clean-ups can now also be scheduled from any node with this responsibility. However, clean-ups are always executed on main nodes. This task can be performed while secondary nodes perform their regular tasks.

Starting with this release, TeamCity can work with GitHub and GitHub Enterprise instances via connections that utilize GitHub Apps. GitHub Apps is the superior way to provide access to your personal and organization repositories. It boasts fine-grained permissions, grants you more control over which repositories the app can access, and does not require keeping a dedicated "service" user to produce OAuth access tokens.

GitHub App connections allow you to check out GitHub.com and GitHub Enterprise repositories, set up webhooks that GitHub uses to notify TeamCity about a repository change, and enable the related authentication module.

Learn more: Configuring Connections.

Starting from this version, you can configure the Pull Requests build feature to ignore GitHub draft pull requests by checking the Ignore Drafts box in the build feature settings. TeamCity will ignore draft pull requests until their status changes.

By default, the Pull Requests build feature loads the GitHub draft pull request information and runs builds on draft pull requests. The build page displays the "Draft" status and grayed-out icon next to the pull request number:

When the status of the draft pull request changes to "Ready for review" in GitHub, the build page reflects the change:

If a VCS root is configured via TeamCity connections to access Git repositories hosted in Bitbucket Server, Bitbucket Cloud or GitLab, the "Authentication Settings" section of this root's settings now displays the Acquire new button. This button allows you to instantly replace the refreshable token used by the VCS Root with a new token issued for the current user.

Short-lived refreshable tokens provide more security compared to passwords or personal access tokens since the TeamCity server refreshes them automatically without sharing any related data with agents.

Learn more: Refreshable tokens.

In addition to Bitbucket Cloud, TeamCity now supports Bitbucket Server and Data Center. The corresponding option is available in the connection types list, and on the Create Project page.

Learn more: Configuring Connections | Creating and Editing Projects

Let's Encrypt is a non-profit Certificate Authority (CA) that provides TLS certificates trusted by all modern browsers. Starting with version 2020.05, TeamCity can contact this CA to automatically issue and set up a valid certificate.

Certificates issued by Let's Encrypt are automatically renewed 30 days before expiration, and cover both your TeamCity server domain and if configured, the artifacts isolation domain.

Learn more: HTTPS Server Settings.

If your TeamCity server allows access via HTTPS, the server's default protocol for communicating with clients is currently TLS Version 1.2. Starting with version 2023.05, you can specify the list of available encryption protocols or force TeamCity to use one specific protocol.

Learn more: Specify Available Encryption Protocols.

TeamCity Service Messages allow you to report various information about the build by adding special messages to your build scripts. The list of available service messages now includes the ##teamcity[notification ...] message that sends emails, Slack direct messages, and posts updates to Slack channels.

Built-in security features ensure messages cannot be sent to wrong recipients and cannot include links to external web resources that are not configured as trusted.

Learn more: Slack Messages | Emails.

You can now send TeamCity service messages to add and remove build tags.

To add and remove tags, send the following messages:

##teamcity[addBuildTag 'your-custom-tag']
##teamcity[removeBuildTag 'tag-to-remove']

Learn more: Service Messages.

IMDSv2 is the new version of the Amazon EC2 Instance Metadata Service that addresses a number of IMDSv1 vulnerabilities.

TeamCity 2023.05 supports EC2 instances and Amazon Machine Images (AMIs) with both "Optional" and "Required" IMDSv2 settings. TeamCity always attempts to use IMDSv2 first, but supports older AMIs as well.

Starting from this version, TeamCity allows customizing Amazon EC2 launch templates. You can now use the same launch template to run various instances that differ in some parameters only. Check the Customize Launch Template box and modify the launch template's values as required.

Learn more: Setting Up TeamCity for Amazon EC2.

Starting with version 2023.05, users who pass the two-factor authentication have one hour to perform security-related actions: disable 2FA, change user password and/or email, and generate access tokens. Once this period expires, users must re-confirm their identities and pass a new 2FA verification before proceeding with these actions.

This new behavior adds an extra layer of protection for your TeamCity server.

Learn more: Critical Settings Protection.

If the global two-factor authentication mode is "Optional", you can now force individual user groups to use 2FA. To do so, add the teamcity.2fa.mandatoryUserGroupKey internal property and set its value to the required group key.

teamcity.2fa.mandatoryUserGroupKey=SYSTEM_ADMINISTRATORS_GROUP

Learn more: Force 2FA for Individual User Groups.

Starting with version 2023.05, you can perform the full range of operations on projects' SSH keys via REST API: upload and generate new keys, modify VCS authentication settings, set passphrases for encrypted keys, and browse and remove uploaded keys. To do this, send required requests to the /app/rest/projects/<project_locator>/sshKeys endpoint.

Learn more: SSH Keys Management.

Our REST API now allows you to manage settings related to storing project settings in VCS. You can use this new API to modify these settings, check for changes, and load/commit changes from/to the related VCS. Explore the /app/rest/projects/{locator}/versionedSettings/ endpoint to view available requests.

Learn more: Manage VCS Settings.

The new /app/rest/roles endpoint allows you to obtain, modify, and remove existing roles, as well as create new ones.

Learn more: Manage Roles and Permissions.

You can now send GET and PUT requests to the /app/rest/server/authSettings endpoint to manage server authentication settings.

Learn more: Manage Server Authentication Settings.

Build configuration pages now display the "Chains" tab. The page allows you to browse Sankey-like diagram of builds linked into a Build Chain.

Previously, this page was available only in Classic UI.

You can now manually reorder builds in the build queue by dragging them to the desired position in the Sakura UI.

• The Change Log tab is now available for projects and build configurations.

• The Show graph option has been implemented on all pages and tabs related to changes. With this option enabled, the changes are displayed as a graph of commits to the related VCS roots.

We have overhauled the Parameters tab on the Build Results Page. You can now use a search box to find required parameters, view only those parameters that were added/modified during a custom build, and hide parameters reported by dependent builds.

Learn more: Parameters Tab.

You can now generate Server Health reports for archived projects. To do this, select the <Archived Projects> scope.

Added two new endpoints that you can check by sending GET requests to obtain the current server status:

• the <server_URL>/healthCheck/healthy endpoint returns "200" if a server is running, even if it is still initializing or in maintenance mode.

• the <server_URL>/healthCheck/ready endpoint returns "200" if a server is fully initialized and ready to accept user requests. If the server is still initializing or awaits for a data upgrade, the endpoint returns "503".