Child pages
  • Lakhnau 2020.1 EAP2 (build 78003) Release Notes
Skip to end of metadata
Go to start of metadata

On this page:

Notifications on build configuration level

TeamCity can use external channels (such as email or Jabber) to notify the registered users about various build events. Previously, notifications were configured only for each TeamCity user or user group. In this EAP, we are presenting the Notifications build feature which allows configuring notifications per build configuration.
This approach doesn’t require referencing a specific TeamCity user and works better for group notifications. Currently, the feature supports email notifications and requires entering a target email only: for example, an email list address. We are working on providing the support for Slack in our next releases.

The Notifications build feature provides the same set of rules as the user-specific notifications and relies on the server Email Notifier settings. To configure similar notifications for many build configurations, you can use a build configuration template.

Support for custom encryption keys

TeamCity stores all secure values used in project configuration files in a scrambled form. The initial values are stored in the TeamCity Data Directory, and their safety primarily depends on the security of your environment. As an extra security level, TeamCity now supports custom encryption keys for scrambling secure values. By using your custom key instead of a default one, you can minimize the risk of potential malicious actions.

To add a custom key, go to Administration | Server Administration | Global Settings and select the Use custom encryption key option. Click Generate to automatically insert a randomly generated custom key. Alternatively, you can enter your own key (AES-256 key encoded with Base64 is supported).


After the settings are saved, all new scrambling operations will be performed with the AES encryption using your custom key.
The existing secure values will remain encrypted with the previous key – you can rescramble them manually using the project’s Actions menu, if necessary. Note that when you change the project settings, all the project’s secure values are reencrypted automatically using the current key.

You can change the custom key or go back to using the default one anytime.

During backup (or project export), your custom keys will be exported along with their projects and automatically available after restoration from backup (or after project import). Since keys will be stored in the exported files in an open form, make sure the export/backup files are well-protected.

More user-level actions on secondary nodes

In TeamCity 2019.2, we provided support for user-level actions on secondary nodes. In this EAP, we are extending the list of available actions with:

  • Adding builds to favorites.
  • Changing settings of user profiles, including general settings, groups and roles, access tokens, VCS usernames, and notification rules.
  • Reordering and hiding projects and build configurations.
  • Checking for pending changes.

 

More actions will become available on secondary nodes in our following releases.

Note that a secondary node allows user actions only if it is assigned with one or more responsibilities.

Experimental UI: Improvements for Project Home

This EAP brings a few handy features to our experimental Project Home page. Note that the TeamCity experimental UI is a work in progress, and the current implementation might change in the future releases.

(1) You can add a child subproject or build configuration directly from the Project Home page.
(2) When viewing the project details, you can instantly see the statuses of build configurations of all the subprojects, even when their blocks are collapsed. Only builds in the default branches are considered.

Other improvements

  • PowerShell as Global Tool
    To improve the cross-platform support of PowerShell and make scripting more convenient, TeamCity now supports PowerShell installed as a .NET global tool.
  • Optimized automatic assignment of investigations on second failure
    If the build configuration has the Investigation Auto Assigner feature enabled and the On second failure option is selected, the investigation will be assigned to the failed build only if the problem repeats in two builds in a row.
    Previously, this behavior applied to all build problems and tests. Since this feature is intended to be used in build configurations with many flaky tests, we narrowed down the scope of affected problems: now, the assignment is delayed for failed tests and "Exit code" build problems only; any compilation error will be assigned with an investigation right on the first failure.
  • Improvement for tests in .NET 3.1 and later
    Implemented support for testing assemblies for the `dotnet test` command (see the related issue).

 


See all fixed issues.

 

  • No labels