TeamCity 2020.2 RC is here

Maria Kudryavtseva

Our Release Candidate build for TeamCity 2020.2 is ready!

The next release version of TeamCity is just around the corner, but our Early Access Program users can be the first to try the new features today.

You can find all 70+ updates and fixes in our tracker. In these EAP notes, we will explore the highlights.

Pull request improvements

Support for Bitbucket Cloud pull requests

Your TeamCity builds can monitor pull requests in different version control systems. And now – in Bitbucket Cloud.

When you send a pull request to a Bitbucket Cloud repo, TeamCity will detect it and run a new build. For this to work, you need to configure the Pull Requests build feature and a VCS trigger.

Note that this feature works a bit differently with Bitbucket Cloud than with other VCSs. Since Bitbucket Cloud does not create a dedicated branch per pull request, TeamCity runs builds on the source branches of pull requests and monitors pull requests only in the same repository (forks are not supported).

See more details in our documentation.

Filtering by source branch

TeamCity can filter pull requests not only by the target but by the source branch. This filter is available for GitHub, GitLab, Bitbucket Server, and Azure DevOps. It allows you to easily eliminate certain draft branches from the scope of monitoring.

Updated pull request icons

We have reworked the icons representing pull requests in build results. They are now bigger and change color depending on the pull request state, helping you to identify its status quicker.

Authenticating with GitLab CE/EE and GitHub Enterprise

In previous EAPs, we provided an ability to sign in to TeamCity using a GitHub.com, GitLab.com, or Bitbucket Cloud account. And now this list is updated with GitLab CE/EE and GitHub Enterprise.

To sign in, click the respective icon. The authentication form will open, and you will be prompted to approve the TeamCity application. If successful, you will be signed in to TeamCity. If your email is verified in both Git hosting and TeamCity, you will be authenticated as this user. Otherwise, TeamCity will create a new user profile, unless this option is disabled.
You can also connect an external account to your TeamCity profile in User Profile | Authentication Settings.

Tip: If you connect with a GitLab profile and want to be recognized by an email, make sure this email is set as public in GitLab.

Admins can map external users with existing TeamCity profiles and restrict authentication to users from the specified GitLab groups or GitHub organizations.

Note that if you reconnect a TeamCity server from one GitLab CE/EE or GitHub Enterprise server to another, TeamCity might not be able to detect external accounts correctly and some users might sign in to wrong TeamCity accounts. This case requires reconfiguring user profiles manually. If you encounter any issues, please contact our support.

Learn how to enable and manage authentication modules in our documentation.

Easier Perforce SSH root configuration

If a VCS root of your project connects to Perforce via SSH, TeamCity can automatically establish a trusted connection. The p4 trust command is now sent every time you test a Perforce connection or a build agent checks out from Perforce.

Experimental UI updates

New Header as default option

In 2020.2 EAP 1 build, we introduced the experimental header. We received a lot of constructive feedback from our users and improved its look and feel since then.

In the released version 2020.2, the new header becomes a default option both in the experimental and classic UI. We hope you find it easy to navigate and use. Share your experience with us: we are actively improving the header’s usability and looking forward to your feedback.

Please note that some plugins developed for the classic header might not work in the new one. If you have troubles with displaying valuable information or actions in the header, you can set the teamcity.ui.useClassicHeader=true internal property – this will switch your TeamCity header to the classic view.
Or, you can learn how to adapt your old UI plugins and write new ones so they are compatible with the new header. We have developed a new API which allows writing modern and effective UI plugins. This blog post gives a quick overview of this API. You can request any extra information right in the comments or via our feedback channels.

Revamped dependencies’ display

We received lots of requests to show queued builds in the experimental UI representation of a build timeline. In this release, we’ve updated the build chain display to give it a more informative look. The Dependencies | Timeline view now shows all dependencies and dependants of the current build, including queued ones.

The full chain is also displayed in the Dependencies | Chain view. You can see all builds that depend on the current one and promote the current build to them, as in the classic UI.

Explore the new views and send us your feedback – we are eager to improve the experimental UI so it grants you the best experience possible.

New build queue page

We are actively working on the new representation of the build queue. You can take a first look at it already in this RC build. The new queue does not open by default: to access it, click the test-tube icon in the upper corner of the screen.

It is now easier to switch between agent pools via the sidebar. You can also expand any build in the queue to quickly access its details.

Branched settings of snapshot dependencies

This feature is released in RC in an experimental state.

If settings of your project are stored in multiple VCS branches and the “Always use settings from VCS” option is enabled, TeamCity will be able to run a build chain with the settings from a non-default branch.
This is another step towards the full support of branched versioned settings. At this point, you can change build steps, parameters, artifacts, and now – snapshot dependencies. Branched settings are helpful if:

• You need to refactor versioned settings. It would be wise to test the new project settings in the background, without affecting the default ones.
• The product source and TeamCity settings are stored in the same repository, and the source code has feature branches.

Previously, TeamCity would not consider settings in the build chain composition if they differ from the settings in the default branch. Now, you can recompose chained builds in a non-default branch, and TeamCity will process these changes properly.

As this functionality is experimental, there are multiple limitations to be considered:

• Promoting builds in a non-default branch is not supported.
• Options of a snapshot dependency in a non-default branch should not differ from the default ones.
• To add new build configurations to a chain, you need to create them in the default branch first. Then, you can reset dependencies between them in a non-default branch.

Other updates

• Passing NuGet packages between build steps
  If you need to use NuGet packages within one build, you want to guarantee they are packed and published in time – and not at the build finish. Previously, it required using a NuGet Publish step. Since this release, a build step can send the ##teamcity[publishNuGetPackage] service message instead. This ensures that the NuGet packages are published in all configured NuGet feeds right at the end of the current build step and are available in the following build steps.
• No default Gradle build file value
  Previously, the Build file field of the Gradle runner was set to build.gradle by default. We have removed this default value as some users rely on custom names of build files and prefer to let Gradle decide what file to choose.
  If you use build.gradle as your build file, all will continue to work as before this update.

Bundled tools updates

• .NET in TeamCity server and agent Docker images (both Windows and Linux) have been updated to version 3.1.403.
• Java in TeamCity Docker images has been updated:
  • On Windows server images: to Amazon Corretto x64 v.11.0.9.11.2
  • On Linux server images: to Amazon Corretto x64 v.11.0.9.11.
  • On Windows and Linux agent images: to Amazon Corretto x64 v.8.272.10.3
• Java bundled in the TeamCity server and agent Windows installers has been updated to version 11.0.9.11.2.
• The Windows image in the TeamCity server Docker containers has been updated to version 2004 (SAC) and 1809 (LTS).
• The Linux image in TeamCity server Docker containers has been updated to version 20.04 (LTS).
• Bundled dotCover and ReSharper CLT have been upgraded to version 2020.2.4.

More features are on their way – stay tuned and check our roadmap for details.

Download Lakhnau 2020.2 RC 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.

You are welcome to share your feedback in our forum or issue tracker.

Happy building!

Subscribe to TeamCity Blog updates

Subscribe form

By submitting this form, I agree to the JetBrains Privacy Policy Notification icon

By submitting this form, I agree that JetBrains s.r.o. ("JetBrains") may use my name, email address, and location data to send me newsletters, including commercial communications, and to process my personal data for this purpose. I agree that JetBrains may process said data using third-party services for this purpose in accordance with the JetBrains Privacy Policy. I understand that I can revoke this consent at any time in my profile. In addition, an unsubscribe link is included in each email.

Submit

Thanks, we've got you!