On this page:
TeamCity now supports OAuth authentication for GitHub.com and Bitbucket Cloud users.
With OAuth, your project members will be able to authenticate on the TeamCity server with their external credentials. In case of GitHub, you can also restrict access to members of your GitHub organization.
To enable OAuth:
In Projects Settings of the Root project, configure a connection to your OAuth provider.
Go to Administration | Server Administration | Authentication.
Switch to the advanced mode and click Add module.
Under HTTP modules, select the required module and configure its settings.
You can also select if TeamCity allows creating new users on login or only authorize existing ones.
When logging in to the TeamCity server, users will be able to choose the necessary provider:
In our next updates, we plan to support OAuth for GitLab and Azure DevOps.
Customizable clean-up schedule
TeamCity server clean-up becomes more flexible with the support of cron-like expressions. Now you can customize the schedule so the clean-up starts with any necessary regularity: for example, on weekends or twice a day.
Remember that too frequent clean-ups might extensively load the CPU, and too rare clean-ups take more time and might lead to garbage accumulation. We recommend keeping the clean-up schedule balanced.
Muting failed tests after successful retry
The TeamCity test retry functionality is convenient for build configurations with flaky tests. Such tests can alternately fail and succeed when applied to the same source revision, and you might want to exclude their influence on the build status. Now, if test retry is enabled, a successful run of a test automatically mutes its previous failure.
To apply this setting to a build configuration, go to Build Configuration Settings | Failure Conditions and enable the "support test retry: successful test run mutes previous test failure" option. Now, TeamCity will mute a failed test if it eventually succeeds during the same build run. This test will not affect the build status, and the build will finish successfully given it has no other problems.
You can instruct your testing framework to enable/disable this failure condition in runtime via the
##teamcity[testRetrySupport enabled='true'] service message.
If you use Kotlin DSL to store project settings, use the following syntax to enable this option:
Commit Status Publisher supports reporting commits to JetBrains Space
The Commit Status Publisher build feature now supports JetBrains Space. With this feature, your TeamCity build statuses can be automatically published to a JetBrains Space project in real-time.
To configure this integration, follow the steps below.
In JetBrains Space:
Go to Administration | Applications and click New application.
Select the Service Account type of the application and enter a convenient name (for example, TeamCity-to-Space publisher).
Click Edit requested rights and enable the Git Repositories | Push commit status permission.
Click Create to save the application.
In the application list, select your new application and copy its autogenerated Client ID and Client secret.
In the Project Settings | Applications of your Space project, add the TeamCity application to the list of authorized apps.
In the project’s settings:
In the build configuration’s settings:
In Build Features, add the Commit status publisher build feature.
Select the JetBrains Space publisher and the recently created connection.
Specify the name that will be displayed for this service in Space.
Save the settings.
Now, whenever you run a build in this configuration, TeamCity will report the build status to JetBrains Space.
Experimental UI updates: new header and support for plugins
The header is still a work in progress – it can be enabled by setting the
teamcity.ui.sakuraHeader=true internal property.
We have also reimagined our approach to creating TeamCity plugins. Now, you can write plugins for the experimental UI using modern web technologies and different frameworks. All existing plugins will continue to work as before.
Follow our blog to learn more about the new plugin functionality – we are about to share details very soon.
- Limiting the number of artifacts published per build
This helps prevent memory consumption problems in case multiple builds publish many artifacts in parallel.
This number is set to 1000 in all new installations. On update of an existing TeamCity installation, this number will be set to unlimited. You can change the value in Administration | Server Administration | Global Settings.
Note that this limit does not consider hidden artifacts.
Execution timeout for composite builds
When a build that is a part of a composite build cannot start (for example, it has no compatible agents), this composite build might run forever until it is terminated manually. Now, you can set an execution timeout for such a build so it fails automatically after being unable to start for a long time.
VCS labels in REST API
See more details in our documentation.
- Support for a path prefix for S3
If you use Amazon S3 to store artifacts, you can now set a path prefix. This will allow using the same S3 bucket for all TeamCity projects and configure prefix-based permissions.
- Health report about insecure Tomcat connection configuration
If the server is installed behind a reversed HTTP proxy, TeamCity now checks if the
scheme="https"attributes are present in the Tomcat connection. If these attributes are missing, TeamCity will display the respective health report.
- The .NET build runner now supports earlier versions of Visual Studio and MSBuild. Currently supported versions are: Visual Studio 2010 or later, MSBuild 4 / 12 or later.
- TeamCity has dropped support for Internet Explorer. It is recommended to use Microsoft Edge or any other supported browser instead.
See all fixed issues.