On this page:
- New flexible clean-up rules
- Context parameters in portable Kotlin DSL
- Managing project secure tokens
- User-level actions on secondary nodes
- New features of experimental UI
- Support of cross-platform dotCover
- Switch to 64-bit Amazon Corretto JVM in Windows installer and Docker images
- Restoring backup on TeamCity startup
- Other improvements
- Upgrade notes
New flexible clean-up rules
Automatic build clean-up has been present in TeamCity since the early versions. It allows conveniently deleting old and no longer necessary build data. While the provided customization options are quite easy to configure, they cover only the most common cases and do not allow for fine-tuning.
With this release, we are introducing more options for flexible control of the clean-up process. In addition to existing “base rule” for a project or build configuration, you can now create multiple “keep rules” to specify what builds and data to preserve during the clean-up. The keep rules are more fine-grained and can cover cases like keeping all the builds with a certain tag (for example, “release”) or in a certain branch. While using the new keep rules requires a better understanding of different kinds of builds and their data, it also offers greater flexibility. We recommend you try the new rules: as soon as you get used to them, you will be able to turn off the base rules and rely exclusively on the keep rules to configure the clean-up logic.
The Clean-up Rules section of Project Settings allows managing base and keep rules for the current project and for its subprojects and build configurations.
When adding a keep rule, you can specify:
Data to preserve: history, artifacts, logs, statistics, or everything.
Builds to consider: what time interval or what number of last builds will be affected by the rule. To cover all the builds, select Forever.
Optionally, limit the builds the rule will apply to:
Build tags. If several tags are entered, the rule will apply to all builds marked with any of these tags.
Build personality. Choose if to limit the builds to personal or non-personal only.
Build branches, by activity status or by the branch name filter.
You can also choose if the rule is applied per each matched branch individually or to all the builds in the selected branches as a single set. For example, if you select to keep statistics of 10 last builds and choose two branches for this rule, you can either select “All selected” to preserve 10 last builds among both selected branches or select “Each selected branch” to preserve 20 last builds – 10 for each of the branches.
Example of a keep rule:
You can edit, disable, or delete keep rules.
The clean-up rules are inherited by subprojects and build configurations from a parent project. If you change the state of an inherited rule, you will be able to reset it to its original definition with the Reset button.
Context parameters in portable Kotlin DSL
When a project stores settings in a portable Kotlin DSL, it is now possible to customize the DSL generation behavior using context parameters configured in the TeamCity UI.
Context parameters are specified as a part of the project versioned settings in the TeamCity UI. The project DSL code checks the values of the context parameters and respectively modifies the generation logic.
Now you can maintain a single Kotlin DSL code and use it in different projects on the TeamCity server, so each of these projects defines its own values of context parameters. Moreover, you can establish a workflow when one team maintains a Kotlin DSL code for projects while the team of Project Administrators customizes it via the context parameters in the TeamCity UI.
Using context parameters
To use a context parameter in a TeamCity project, you need to (1) define it in the project versioned settings in the UI and (2) reference it in the project DSL.
- Managing context parameters in UI
You can manage project context parameters on the Versioned Settings | Context Parameters tab. The tab is only available if the “Generate portable DSL scripts” option is enabled.
After you add, edit, or delete the parameters and click Save, TeamCity will reload the DSL configuration and apply the changed values to the project settings.
Referencing context parameters in DSL
To reference a context parameter in the
settings.ktsfile, use the
getParameter()method of the
DslContextobject. You can specify a default value of this parameter as an optional second argument:
The following example shows how to use context parameters in DSL:
Each context parameter is expected to have a value, either the default one, set in the DSL, or a project-specific one, set in the UI. When you create a project from DSL or update the project versioned settings, TeamCity detects all context parameters with missing values and prompts you to set them.
Context parameters in Maven
If you use Maven to locally test the DSL, you can specify context parameters in the
<contextParameters> block of the
pom.xml file. For the example above:
Managing project secure tokens
When the “Store secure values outside of VCS” option is enabled in the project Version Settings | Configuration, TeamCity maintains own storage of secure tokens (passwords and other secure values) for the project, without checking them into the version control – to prevent their exposure. In this release, we add additional control over these values stored by TeamCity.
The Version Settings | Tokens tab allows viewing and copying all the project tokens and generating new ones.
On this tab, you can also access unused project tokens.
When secure data of a project is stored outside of the Version Control System, it could potentially be detached from the project: for example, when a project with tokens is moved to another place in the hierarchy or created from DSL on the new TeamCity server. As a result, the project will not be able to use tokens detached from their secure values. Now you can specify values for missing tokens on the Tokens tab.
User-level actions on secondary nodes
In previous versions of TeamCity secondary nodes showed mostly read-only interface. It was not possible to add builds to the queue, tag/pin builds, or perform any other user-level actions. With this release, it changes. Now, if a secondary node is granted any responsibility (that is it does not act as a read-only server), it will enable build actions for users.
Currently, supported user-level actions are:
- Triggering a build, including a custom or personal one
- Stopping a build
- Pinning/tagging/commenting a builds
- Deleting a build
- Assigning investigations and muting build problems and tests
- Marking a build as successful/failed
- Merging sources and label sources actions
See the full list of supported actions in our tracker: TW-62749.
New features of experimental UI
We encourage you to try out the TeamCity experimental UI and leave any feedback!
New Changes and Tests tabs of Build Details
The recently introduced experimental Build Details page now provides redesigned Changes and Tests tabs.
The Changes tab displays all primary information about changes in the build.
Click on any change to preview its details:
The new Tests tab allows quickly switching between failed, ignored, and succeeded tests. Click on a test to view its details and assign an investigation.
New Agents page
See our first take on redesigning the display of build agents in the experimental UI. The page is currently in active development, but you can already try the new features:
- The experimental Agents page loads faster for a large number of agents and allows quickly switching between agent details.
- You can use the sidebar to browse the agent pool hierarchy and search agents and pools by name.
- The Reports page provides statistics about running, idle, and disconnected agents in every pool.
Support of cross-platform dotCover
TeamCity now allows collecting coverage for .NET Core projects on Linux and macOS by supporting cross-platform JetBrains dotCover, version 2019.2.3+.
dotCover 2019.2.3 for Windows is bundled with TeamCity. If you need to collect code coverage under non-Windows platforms, add the cross-platform dotCover tool under Administration | Tools and enable the dotCover coverage in the .NET CLI build step. If you want to use cross-platform dotCover under Windows as well, make sure the agents have .NET Framework SDK 4.6.1+ installed.
Now you can also run code coverage analysis with dotCover inside a Docker container, with the Docker Wrapper extension.
Switch to 64-bit Amazon Corretto JVM in Windows installer and Docker images
Previous versions of TeamCity bundled 32-bit JVM from Oracle and then from AdoptOpenJDK. Given that 64-bit systems are now the most widespread, we decided to switch to 64-bit JVM in our Windows installer. This should simplify the maintenance of the TeamCity server because 32-bit JVM has quite limiting maximum amount of memory which can be used by the server process on Windows (about 1.2 Gb). Previously, when server administrators needed to increase
Xmx beyond this value, they had to change JVM as well – this is no longer the case.
In addition, we decided to switch the bundled JVM from AdoptOpenJDK to Amazon Corretto JVM in the Windows installer and in our Docker images. AdoptOpenJDK served us quite well and we did not have problems with it. This decision is a part of internal unification processes in JetBrains. It should not affect TeamCity users anyhow.
Restoring backup on TeamCity startup
If you start the TeamCity server instance for the first time and want to restore the backed up data of your previous TeamCity installation, you can now restore the backup right from the startup screen UI.
- Project administrators with enabled “Change user / group notification rules in project“ permission will be able to edit notification rules for users and user groups assigned to their projects.
- You can use a branch filter with filter masks in a Pull Requests build feature. If the filter pattern is specified, TeamCity will monitor and trigger pull requests only on matching branches.
- Now you can re-run personal builds, just like regular builds: open the context menu of a finished build and click Re-run this build.
- TeamCity can automatically manage the amount of memory used by the
If you have previously used the
teamcity.git.fetch.process.max.memoryinternal property to set the memory amount available for fetching in each VCS root, you can now disable it to delegate the detection of memory consumption to the TeamCity server. You can control the limit of available memory via the
- All fixed issues