TeamCity 2024.07 is out! With this release, we’re introducing a number of important features, such as a new licensing mechanism that simplifies the management of TeamCity server and agent licenses.
There’s also the new GitHub Checks webhook trigger that allows you to queue builds instantly after pushing a commit to GitHub and receive updates in rich text format.
Additionally, the new Problems page provides a unified place for reviewing any issues with TeamCity tests and builds.
Read on to learn more about these features and other highlights of this release.
New licensing mechanism for JetBrains accounts
In version 2024.07, we’re introducing an option for TeamCity admins to activate licenses through a unified JetBrains Account. This new feature aims to simplify license management for TeamCity server and agent licenses through your JetBrains Account.
Previously, TeamCity Enterprise customers faced challenges with separate license keys for each build agent license or Enterprise server pack, especially for keys with different expiration dates. Offline keys require manual generation, download, and input into the TeamCity server.
Additionally, there was no flexibility to distribute agent licenses among multiple TeamCity servers, as customers had to manually transfer keys between servers. Furthermore, users couldn’t split agents from a single server pack between servers.
Now, you can simply log into your JetBrains Account from the Licenses page in TeamCity and select a server license for activation. Once connected, TeamCity will automatically update all server and agent licenses, eliminating the need to manually enter license keys for additional agents or license renewals.
TeamCity Professional users will also benefit from this new feature. Thanks to the unified JetBrains Account login, you’ll be able to stay better informed on all product updates and important security fixes.
Learn more about the JetBrains Account login in our documentation.
Custom path in the repository for versioned settings
In TeamCity, you can configure your projects and settings programmatically using the Kotlin DSL and XML format.
Previously, if a project had versioned settings stored in VCS, TeamCity would track only the .teamcity directory. TeamCity could still store versioned settings for all subprojects within a single repository, but only if the main project had versioned settings enabled. This was inconvenient in certain scenarios. For instance, a broken DSL in a main project blocked updates for all subprojects and other builds.
Another disadvantage of the previous approach is that if changes in one project triggered the Kotlin DSL compilation, the settings were applied to other projects stored in the same repository, even when the applied changes weren’t supposed to affect them.
In addition, users with large nested projects had to use different repositories to store versioned settings for different projects.
We’re now adding the ability to configure custom paths in the repository for versioned settings in TeamCity.
This feature is handy in the following scenarios:
- If you have a monorepo with many projects and want to store settings for the subprojects, even if these subprojects aren’t interconnected.
- If you have several projects stored in a single repository.
- If you use your repository to exclusively store versioned settings, there is now an option to store them in the repository root, rather than a
.teamcitysubdirectory.
Read more about this feature in our documentation. Feel free to leave your comments in the corresponding YouTrack issue.
GitHub Checks webhook trigger
This new TeamCity feature allows you to queue builds instantly after pushing a commit to GitHub. It also publishes build statuses and details – such as problems or information about failed tests – in Markdown as GitHub checks.
This trigger is compatible with GitHub App connections that have webhooks enabled.
Learn more about this feature in our documentation.
Uploading SSH keys when creating project or VCS roots from URLs
TeamCity allows you to create projects or VCS roots from a URL.
Previously, the form for creating a project or build configuration from a URL accepted credentials such as username and password/access token only. This limitation restricted project admins from using SSH fetch URLs for Git VCS roots configured in this manner.
We reworked the authentication form so that you can manually choose either the Password/Access token or the SSH key option as the authentication type.
TeamCity will also automatically detect and suggest the appropriate authentication type when you insert the URL into the corresponding field.
The form’s new SSH key authentication supports passphrases, which are stored in the generated VCS root directory and used for this specific project or build configuration.
Learn more about the ability to upload SSH keys in our documentation.
Perforce Helix Core improvements
Customizing VCS label descriptions for Perforce (P4)
Thanks to its integration with Perforce Helix Core, TeamCity can build sources of projects stored in a Helix Core repository and apply automatic labels to sources and other elements.
Thanks to the VCS labeling build feature, TeamCity can label (tag) sources of a particular build in Perforce – both automatically and manually.
In version 2024.07, we’re adding the ability to customize VCS label descriptions, allowing you to be more specific in your descriptions. Similar to the existing labeling pattern settings, all TeamCity build parameters are available.
For instance, you can configure the VCS labeling build feature to display a TeamCity build or changelist number.
Head over to our documentation to learn more about how to configure VCS label descriptions for Perforce and other VCSs.
Support for Perforce ditto mappings
For some time, Perforce Helix Server has had a one-to-many mapping feature, which allows users to map a single depot path to multiple locations in a client workspace. This feature is also known as ditto mapping.
Starting from the 2024.07 version, ditto mapping is supported by TeamCity, too.
Running a custom task before checkout
We’re introducing a new feature called bootstrap steps that allows users to perform tasks before the checkout process runs on the agent. This helps identify and solve any locking issues, enables the working directory to be customized prior to checkout, and allows other actions to be performed on the agent before checkout.
When this feature is enabled, the build step configuration screen contains a Run during bootstrap option, enabling these bootstrap steps to be executed before all other build steps and prior to checkout.
Learn more about bootstrap steps in our documentation.
Prometheus counter for unassignable builds in queue
In certain scenarios, such as when TeamCity parameters are modified or the agent pool is depleted, jobs can stall indefinitely because they cannot be assigned to any agents.
In version 2024.07, we’re implementing the new build_queue_incompatible metric, which reflects the current number of builds without compatible agents in the build queue.
Sakura UI: Reworked Problems page
TeamCity provides an overview of current problems and investigations at both the project and build levels. Users can manage build configuration errors, failed tests, muted problems, and ongoing investigations, as well as the assignee and status of each issue.
We reworked the UI to give our users a clearer overview of all issues and their statuses, which can now be found on the unified Problems page.
This new, sleek design provides users with a single spot from where they can review and act upon all existing build issues.
For the full list of new features, please see our release notes.
As always, feel free to reach out to us with any questions or suggestions via our forum or the contact form on our website.
Happy building!