Upgrading DSL
The TeamCity XML settings format is usually changed in the major releases. During the first start after the server update, TeamCity converts XML settings files in the TeamCity Data Directory to the new format. When settings are stored in Kotlin DSL, the Kotlin code might need to be changed to remain functional. It is also recommended to update the Kotlin code to the latest config version.
These recommendations are displayed as server health reports on the corresponding pages of the server administration UI.
As far as the DSL is concerned, there are the following types of TeamCity settings changes.
These types of settings changes do not require changing the Kotlin DSL as the changes are applied by the server automatically on each settings regeneration from the DSL.
It is recommended though to update the DSL to a newer configs version to reduce performance hit and make Kotlin scripts closer to the settings you see in the UI.
A lot of changes in TeamCity settings fall into this category. For example, some plugin implementing a build step may rename its parameters.
The DSL from the previous TeamCity version generates a parameter with the old name, but TeamCity can automatically replace the old parameter name with the new one after DSL execution.
Some TeamCity settings changes require external information and cannot be performed automatically. For example, in TeamCity 10.0 the settings of the cloud integration were stored in a dedicated file which was not committed to a VCS. In TeamCity 2017.1, these settings were moved to the project level. TeamCity cannot perform such a transformation of settings automatically without external data, so manual DSL code update is required.
This is the version specified in settings.kts
, it looks like this:
version = "2024.12"
TeamCity uses this version to perform transformations after DSL execution to make resulting XML configuration files up-to-date with the current TeamCity version where they will be applied. For instance, your DSL scripts could be generated by TeamCity 2017.2 and have the version set to 2017.2
. When you upgrade your server to version 2022.04
, TeamCity will execute your DSL and apply additional transformations to modify the settings according to the format expected by the newest version.
The DSL code generated by TeamCity before 2022.04
has the DSL API version encoded into the package name, for example: jetbrains.buildServer.configs.kotlin.v2019_2
. The v2019_2
part there corresponds to the TeamCity version when this DSL API was introduced.
The new DSL API version is introduced when there are significant incompatible changes in DSL API. However, after TeamCity 2019.2 there were no incompatible changes. So several TeamCity versions after that still used the same v2019_2
package names for the newly generated DSL code. Because of the lack of incompatible changes starting with TeamCity 2022.04
the DSL API version is considered redundant, and it is recommended to perform a switch to packages without this version.
If your versioned settings are stored in the Kotlin format, upgrading a TeamCity server to a newer version employs converters that automatically update your DSL code so that it remains functional.
However, TeamCity may turn off versioned settings for projects that store these settings in the XML format. This behavior occurs if a server upgrade leads to changes in settings XML files and is designed to prevent unwanted configuration updates when upgrading to a non-production version of the TeamCity server.
If your new TeamCity version is stable and you wish to proceed with the XML files' update, click the corresponding health report action. TeamCity will commit updated XML configuration files to the VCS. This commit will also include all project configuration updates made via TeamCity UI while the versioned settings were disabled.
Usually, after the server upgrade, the Kotlin DSL scripts do not require any immediate changes and should produce the same result in the new TeamCity version. However, it is recommended to update the Kotlin DSL scripts to use the most recent configs version.
tip
Instead of upgrading your DSL manually, you can always regenerate all the Kotlin DSL scripts for your projects. To do this, you can disable and enable versioned settings again, and select the " Overwrite " option in the confirmation dialog. After that, TeamCity will make a commit to your VCS repository removing all previously generated Kotlin files and adding newly generated files corresponding to the current TeamCity version.
If Kotlin DSL scripts were changed in the repository and these changes can't be lost, then the manual upgrade is recommended.
The settings.kts
contains a so-called configs version:
version = "2024.12"
This version should be changed to the current version of the TeamCity server. For instance, if TeamCity server was upgraded to 2024.12
, then 2024.12
should be specified in the settings.kts
.
But before doing so, you should first review the health reports produced by your TeamCity server after it applied the most recent changes in your DSL scripts. These health reports describe what changes should be done to your DSL before you could safely change configs version.
If you see a message like:
Please change the configs version to "%product-version%" in projects:
<the list of projects>
then no additional changes to your DSL are required and you can change the config's version
to 2024.12
. Otherwise, you will receive the following message:
DSL scripts should be updated to produce settings for version %product-version%:
change DSL for build configurations:
<affected build configurations>
to update DSL, do the following:
<description of what should be changed>
You should review these suggestions and apply them to your DSL scripts. The configs version can be changed only after all these suggestions are applied.
The bundled Kotlin version has been updated to 2.0.21. The language version remains 1.9. We hope to bump the language version in future releases, along with migrating to the K2 compiler. See the K2 migration guide to check whether this change will affect your custom Kotlin code.
The bundled Kotlin version has been updated to 1.8.22.
For security reasons, existing AWS connections can now be used only those TeamCity project that own these connections. Child sub-projects cannot access connections of their parent projects. To allow a subproject to use the AWS connection of its parent project, add the
allowInSubProjects = true
parameter to this connection's settings block.
The bundled Kotlin version has been updated to 1.7.10.
The Pull Requests build feature for build configurations targeting Bitbucket Server/Data Center repositories no longer tracks officially unsupported pull request branches (and watches source branches instead). To manually switch to the previous (deprecated) behavior, add the
usePullRequestBranches = true
parameter to your Pull Requests feature(s). See this TeamCity Kotlin DSL documentation article for more information: PullRequests.
The bundled Kotlin version has been updated to 1.6.21.
New DSL API artifacts without version in package names are introduced. See below how to switch to these DSL API artifacts.
Starting with TeamCity 2022.04 it is recommended to remove the version part of the imports in your DSL code to make the DSL code look simpler and improve code completion suggestions in IntelliJ IDEA.
For example, the imports:
import jetbrains.buildServer.configs.kotlin.v2019_2.*
import jetbrains.buildServer.configs.kotlin.v2019_2.projectFeatures.*
can be changed to:
import jetbrains.buildServer.configs.kotlin.*
import jetbrains.buildServer.configs.kotlin.projectFeatures.*
To remove the DSL API version from the imported package names, the following should be done:
Update
<dependencies/>
section of the pom.xml fileThe artifactId
configs-dsl-kotlin
should be changed toconfigs-dsl-kotlin-latest
andconfigs-dsl-kotlin-plugins
should be changed toconfigs-dsl-kotlin-plugins-latest
In the end
<dependencies/>
section should look like:
<dependencies>
<dependency>
<groupId>org.jetbrains.teamcity</groupId>
<artifactId>configs-dsl-kotlin-latest</artifactId>
<version>${teamcity.dsl.version}</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.jetbrains.teamcity</groupId>
<artifactId>configs-dsl-kotlin-plugins-latest</artifactId>
<version>1.0-SNAPSHOT</version>
<type>pom</type>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.jetbrains.kotlin</groupId>
<artifactId>kotlin-stdlib-jdk8</artifactId>
<version>${kotlin.version}</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.jetbrains.kotlin</groupId>
<artifactId>kotlin-script-runtime</artifactId>
<version>${kotlin.version}</version>
<scope>compile</scope>
</dependency>
</dependencies>
Make sure TeamCity server is up and running.
The artifact with id
configs-dsl-kotlin-plugins-latest
is provided by the TeamCity server. This is the same TeamCity server which is specified in the<repositories/>
section of the pom.xml with idteamcity-server
. Maven should be able to download the artifactconfigs-dsl-kotlin-plugins-latest
, hence this server should be up and running.Change imports in all the Kotlin files.
The version part of the package name should be removed in all the Kotlin files, for instance:
import jetbrains.buildServer.configs.kotlin.v2019_2.*
should be replaced with:
import jetbrains.buildServer.configs.kotlin.*
Compile DSL and generate settings.
After the changes to pom.xml and Kotlin files, it is recommended to run
mvn teamcity-configs:generate
task to ensure that the project still compiles. If there are no errors, then these changes can be checked into the versioned settings repository.
This release does not introduce a new DSL API package, so v2019_2 remains the latest one.
The bundled Kotlin version has been updated to 1.5.31.
Typed DSL is now supported for numerous settings of projects and build configurations. See the whole list of improvements here.
This release does not introduce a new DSL API package, so v2019_2 remains the latest one.
The bundled Kotlin version has been updated to 1.4.32.
The
useMirrors
parameter in Git VCS roots is deprecated and replaced by thecheckoutPolicy
parameter that supports the following values:AUTO
,USE_MIRRORS
,NO_MIRRORS
,SHALLOW_CLONE
.
Git VCS roots in the project DSL code should be updated accordingly. For instance,useMirrors=false
should be replaced withcheckoutPolicy=NO_MIRRORS
, whileuseMirrors=true
withcheckoutPolicy=USE_MIRRORS
. IfuseMirrors
was not specified in a Git VCS root, thencheckoutPolicy=USE_MIRRORS
should be added.
Read more about these checkout policies here.The Python build steps' default value for the
installToolPackage
field has been changed. Since 2021.1,installToolPackage
istrue
by default. To preserve the current behavior of the Python build steps, addinstallToolPackage = false
to the build step settings.
This release does not introduce a new DSL API package, so v2019_2 remains the latest one.
The bundled Kotlin version has been updated to 1.4.21.
This release does not introduce a new DSL API package, so v2019_2 remains the latest one.
The bundled Kotlin version has been updated to 1.3.70.
The bundled Kotlin version has been updated to 1.3.60.
This release introduces the new DSL API package: v2019_2. This package has an updated API for clean-up rules and provides an ability to obtain DSL context parameters' values inside the Kotlin DSL scripts.
Parameters of the ReportTab project features should be changed:
The
revisionRuleRevision
parameter should be removed if the value of therevisionRuleName
parameter is set tolastFinished
,lastSuccessful
, orlastPinned
.The
revisionRuleRevision
parameter should be renamed torevisionRuleBuildNumber
if the parameterrevisionRuleName
has thebuildNumber
value.The
revisionRuleRevision
parameter should be renamed torevisionRuleBuildTag
and suffix.tcbuildtag
should be removed from the parameter's value if the parameterrevisionRuleName
has the valuebuildTag
.
Since TeamCity 2019.2, use the DslContext.baseDir
property to access a file under the .teamcity
directory from DSL scripts. For example:
val dataFile = File(DslContext.baseDir, "data/setup.xml")
This is required because TeamCity 2019.2 no longer guarantees that the current working directory for DSL scripts is the .teamcity
directory.
This release introduces the new DSL API version, v2019_1, but its package is still jetbrains.buildServer.configs.kotlin.v2018_2
because there were no significant changes in the DSL between versions 2018.2.x and 2019.1.x.
The DSL producing Maven build steps should be updated. If a Maven build step did not have the useOwnLocalRepo
parameter set to true
, the following localRepoScope
parameter should be added:
maven {
...
localRepoScope = MavenBuildStep.RepositoryScope.MAVEN_DEFAULT
}
If useOwnLocalRepo
was set to true
, then it should be replaced with:
maven {
...
localRepoScope = MavenBuildStep.RepositoryScope.BUILD_CONFIGURATION
}
If MSBuild or VS.Solution build steps have the parameter toolsVersion
set to MSBuildStep.MSBuildToolsVersion.V15_0
, the additional version = MSBuildStep.MSBuildVersion.V15_0
parameter should be added:
msBuild {
...
toolsVersion = MSBuildStep.MSBuildToolsVersion.V15_0
version = MSBuildStep.MSBuildVersion.V15_0
}
The build configuration version control settings parameter buildDefaultBranch
is deprecated: branchFilter
should be used instead.
For instance, if buildDefaultBranch
was set to false
, the following branch filter should be specified instead:
vcs {
branchFilter = """
+:*
-:<default>
"""
}
This release introduces the new DSL API version, v2018_2, its package is jetbrains.buildServer.configs.kotlin.v2018_2
.
This release introduces the new DSL API version, v2018_1, its package is jetbrains.buildServer.configs.kotlin.v2018_1. The previous API versions work and you can keep using them if you don't want to use portable DSL scripts.
If you used Kotlin DSL with TeamCity 2017.2 for Docker plugin configurations, you may need to perform some changes in your Kotlin configuration scripts to make your code compatible with TeamCity 2018.1.
The essence of the changes:
build step dockerBuild is now converted to dockerCommand
the parameters for DockerBuild are now sub-parameter for commandType selector
Note the difference:
Docker Build 2 Docker Command migration
# DockerBuild in 2017.2:
dockerBuild {
name = "name of the build step"
source = content {
content = """
FROM busybox
MAINTAINER KIR <kir@maxkir.com>
""".trimIndent()
}
namesAndTags = "maxkir/maxkir_test"
}
#----------------------------------------
# DockerBuild in 2018.1:
dockerCommand {
name = "name of the build step"
commandType = build {
source = content {
content = """
FROM busybox
MAINTAINER KIR <kir@maxkir.com>
""".trimIndent()
}
namesAndTags = "maxkir/maxkir_test"
}
}
dockerCommand {
name = "name of the push step"
commandType = push {
namesAndTags = "maxkir/maxkir_test"
}
}
Since TeamCity 2018.1 Gerrit publisher settings in the Commit Status Publisher build feature allow customising the Gerrit label that reflects the build status, i.e. now you can use something other than Verified.
To manually modify Kotlin DSL settings, the label = "Verified" statement must be added as follows:
features {
...
commitStatusPublisher {
publisher = gerrit {
server = "<server>"
gerritProject = "<project>"
failureVote = "-1"
successVote = "+1"
userName = "<user>"
uploadedKey = "<key>"
label = "Verified" // the statement to be added
}
}
...
}
This release introduces the new DSL API version, v2017_2
. The previous API version works and you can keep using it if you do not need the features provided by the new API.
note
To get sample DSL code for the newly supported features without switching a project to the Kotlin format, use the Download settings in Kotlin format action on the project administration page.
If you used 2017.2 EAPs and tested changing DSL settings via the UI, you need to apply all the UI patches created by TeamCity before upgrading as some API is changed in an incompatible way.
The current package name for the settings generated by TeamCity is jetbrains.buildServer.configs.kotlin.v2017_2
.
With the new API, you can benefit from a number of new features, including the editable administration UI for Kotlin DSL projects and DSL documentation. To use them for your existing project, your .kt
files should be switched to packages from the v2017_2 version
.
To compile this project, you also need to update your pom.xml. The easiest way is to invoke the Download settings in Kotlin format action in your project and copy the
pom.xml
from the generated zip archive. Alternatively you can update pom.xml yourself with the following:change
teamcity.dsl.version
to:<teamcity.dsl.version>2017.2</teamcity.dsl.version>
change the kotlin version to:
<kotlin.version>1.1.4-3</kotlin.version>
and add a dependency on kotlin\-runtime and kotlin\-reflect:
<dependency>
<groupId>org.jetbrains.kotlin</groupId>
<artifactId>kotlin-runtime</artifactId>
<version>${kotlin.version}</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>org.jetbrains.kotlin</groupId>
<artifactId>kotlin-reflect</artifactId>
<version>${kotlin.version}</version>
<scope>compile</scope>
</dependency>
Once you switch the project to new API and check in the changes, TeamCity will detect and apply them and after that web UI editing will be enabled.
To use the new DSL API in a repository with an existing pom.xml
, the maven dependency version has to be updated to 2017.2
.
If you used Kotlin DSL with TeamCity 2017.1 for Docker plugin configurations, you may need to perform some changes in your kotlin configuration scripts to make your code compatible with TeamCity 2017.2. Basically, TeamCity provides a converter for Kotlin configuration scripts to perform those changes automatically, but if it does not work due to some reason, the following changes need to be made manually:
rename the build runner step with the Docker Build runType to DockerBuild
rename the build runner step with the Docker Compose runType to DockerCompose
rename the
docker-compose.file
build parameter todockerCompose.file
Starting from TeamCity 2017.2, the Docker plugin has its own typed DSL for the Docker Support build feature, Container Wrapper, Docker, and Docker Compose runners.
Docker Compose and Docker Build
steps {
dockerCompose {
name = "Start services"
file = "db-tests/scripts/docker-compose.yml"
}
dockerBuild {
name = "Docker build step"
source = path {
path = "some/context/Dockerfile"
}
// Case for Dockerfile specified by an URL:
//source = url {
// url = "https://raw.githubusercontent.com/JetBrains/teamcity-docker-minimal-agent/master/ubuntu/Dockerfile"
//}
// Case for Dockerfile specified by text:
//source = content {
// content = """
// FROM busybox
// MAINTAINER Kirill Maximov <kir@jetbrains.com>
// """.trimIndent()
//}
contextDir = "some/context"
namesAndTags = "my:tag"
}
}
Docker Build Feature
features {
dockerSupport {
cleanupPushedImages = true
loginToRegistry = on {
dockerRegistryId = "PROJECT_EXT_2"
}
}
}
Command Line runner with Container Wrapper
script {
scriptContent = "ls -lR"
dockerImage = "openjdk:8u121"
dockerPull = true
dockerRunParameters = "--rm -v /some/path:/another/path:ro"
}
Since 2017.2 EAP3, TeamCity supports default templates in projects. This setting was stored in a project feature of the "DefaultTemplate" type in EAP3 and EAP4, but since 2017.2 RC the project configuration schema was changed to accommodate for default templates.
To manually convert a DSL project configuration that employs the default template, you will have to delete a corresponding project feature and replace it with the defaultTemplate property assignment as follows:
2017.2 EAP3/4 DSL project configuration with a default template configured:
object Project : Project({
uuid = "2b241ffb-9019-4e60-9a3a-d5475ab1f312"
extId = "ExampleProject"
parentId = "_Root"
name = "Example Project"
...
features {
...
feature {
id = "PROJECT_EXT_4"
type = "DefaultTemplate"
param("template", "ExampleProject_MyDefaultTemplate")
}
...
}
...
})
2017.2 DSL project configuration with the default template configured:
object Project : Project({
uuid = "2b241ffb-9019-4e60-9a3a-d5475ab1f312"
extId = "ExampleProject"
parentId = "_Root"
name = "Example Project"
defaultTemplate = "ExampleProject_MyDefaultTemplate"
...
features {
...
}
...
})
Since 2017.2, TeamCity had been bundling the .NET CLI plugin (now reintroduced as the .NET runner). If you were using Kotlin DSL for the plugin parameters in TeamCity 2017.1.x, you need to change the commands as follows. In TeamCity 2017.1.x:
steps {
step {
type = "dotnet"
param("dotnet-command", "build")
param("dotnet-paths", "WindowsAzure.sln")
}
}
Since TeamCity 2017.2, you can explicitly specify build steps with parameters:
steps {
dotnetBuild {
projects = "WindowsAzure.sln"
}
}
2017.1 | 2017.2 | Comment |
---|---|---|
dotnet\-command | dotnet<Command> | Now the command name reflects the build step name, e.g. |
dotnet\-args | args | |
dotnet\-verbosity | logging |
2017.1 | 2017.2 | Comment |
---|---|---|
dotnet\-paths | projects | |
dotnet\-build\-config | configuration | |
dotnet\-build\-framework | framework | |
dotnet\-build\-output | outputDir | |
dotnet\-build\-runtime | runtime | |
dotnet\-build\-no\-deps | \- | Should be added as the |
dotnet\-build\-not\-incremental | \- | Should be added as the |
2017.1 | 2017.2 |
---|---|
dotnet\-paths | projects |
dotnet\-clean\-config | configuration |
dotnet\-clean\-framework | framework |
dotnet\-clean\-output | outputDir |
dotnet\-clean\-runtime | runtime |
2017.1 | 2017.2 |
---|---|
dotnet\-paths | projects |
dotnet\-msbuild\-config | configuration |
dotnet\-msbuild\-platform | platform |
dotnet\-msbuild\-targets | targets |
dotnet\-msbuild\-runtime | runtime |
2017.1 | 2017.2 |
---|---|
dotnet\-nuget\-delete\-id | packageId |
dotnet\-nuget\-push\-source / dotnet\-nuget\-delete\-source | packageSource |
secure:dotnet\-nuget\-delete\-api\-key | apiKey |
2017.1 | 2017.2 | Comment |
---|---|---|
dotnet\-paths | packages | |
dotnet\-nuget\-push\-source | packageSource | |
dotnet\-nuget\-push\-no\-symbols | noSymbols | |
secure:dotnet\-nuget\-push\-api\-key | outputDir | |
dotnet\-build\-runtime | apiKey | |
dotnet\-nuget\-push\-no\-buffer | \- | Should be added as the |
2017.1 | 2017.2 | Comment |
---|---|---|
dotnet\-paths | projects | |
dotnet\-pack\-config | configuration | |
dotnet\-pack\-runtime | runtime | |
dotnet\-pack\-no\-build | skipBuild | |
dotnet\-pack\-output | outputDir | |
dotnet\-pack\-version\-suffix | versionSuffix | |
dotnet\-pack\-serviceable | \- | Should be added as the |
2017.1 | 2017.2 |
---|---|
dotnet\-paths | projects |
dotnet\-publish\-config | configuration |
dotnet\-publish\-framework | framework |
dotnet\-publish\-output | outputDir |
dotnet\-publish\-runtime | runtime |
dotnet\-publish\-version\-suffix | versionSuffix |
2017.1 | 2017.2 | Comment |
---|---|---|
dotnet\-paths | projects | |
dotnet\-restore\-config | configFile | |
dotnet\-restore\-runtime | runtime | |
dotnet\-restore\-packages | packagesDir | |
dotnet\-restore\-source | packageSources | |
dotnet\-restore\-ignore\-failed | \- | Should be added as the |
dotnet\-restore\-no\-cache | \- | Should be added as the |
dotnet\-restore\-parallel | \- | Should be added as the |
dotnet\-restore\-root\-project | \- | Should be added as the |
2017.1 | 2017.2 |
---|---|
dotnet\-paths | projects |
dotnet\-run\-config | configuration |
dotnet\-run\-framework | framework |
dotnet\-run\-runtime | runtime |
2017.1 | 2017.2 |
---|---|
dotnet\-paths | projects |
dotnet\-test\-config | configuration |
dotnet\-test\-framework | framework |
dotnet\-test\-no\-build | skipBuild |
dotnet\-test\-output | outputDir |
dotnet\-test\-settings\-file | settingsFile |
dotnet\-test\-runtime | runtime |
dotnet\-test\-test\-case\-filter | filter |
2017.1 | 2017.2 | Comment |
---|---|---|
dotnet\-paths | assemblies | |
dotnet\-vstest\-config\-file | settingsFile | |
dotnet\-vstest\-framework | framework | |
dotnet\-vstest\-platform | platform | |
dotnet\-vstest\-filter\-type | filter | To filter tests by name, use |
dotnet\-vstest\-is\-isolation | \- | Should be added as the |
TeamCity 2017.1 does not introduce a new Kotlin DSL API, the same package as in TeamCity 10.0.x is used (jetbrains.buildServer.configs.kotlin.v10
). Several new properties were added to the existing API; to get the latest API for the scripts development, update teamcity.dsl.version
in pom.xml
to the 2017.1-SNAPSHOT
for EAP builds and to the 2017.1
for release builds.
These changes should be performed before enabling versioned settings in the projects where they were disabled on TeamCity upgrade with the message: "Versioned settings are disabled in this project because its settings files were modified during TeamCity upgrade".
This is only relevant if you use Kotlin DSL for the Root project settings and have cloud profiles.
In 2017.1 cloud profiles were moved from the server level to the Root project level. Since they were not defined in the Kotlin DSL, in case you enable the versioned settings the existing cloud profiles will be deleted form he server. Thus before continuing to use Kotlin DSL for the root project on the server make sure to add the cloud profiles definitions to the root project settings in Kotlin DSL.
To update your settings with the cloud profile information, perform the following:
Run the 'Download settings in Kotlin format' action in the Root project and save the zip with the generated DSL.
Copy project features of type
CloudIntegration
andCloudProfile
from the.teamcity/_Root/Project.kt
file to the root project config in your settings.Commit your changes to the VCS.
Enable versioned settings on the Versioned Settings tab of the Root project.
Due to the fix of issue TW-48609, if your settings contain nameless entities, TeamCity will report corresponding VCS settings errors. You need to manually set a name parameter to such entities to resolve the errors.
The changes in this section should be done to Kotlin scripts on changing the scripts config version from 10.0 to 2017.1
Parameters used by DotCover were changed and if you use them, make sure dotNetCoverage.tool
has the dotcover
value. If the dotNetCoverage.dotCover.home.path
parameter is missing, set it to %teamcity.tool.JetBrains.dotCover.CommandLineTools.bundled%
. The result should look like this:
param("dotNetCoverage.tool", "dotcover")
param("dotNetCoverage.dotCover.home.path", "%\teamcity.tool.JetBrains.dotCover.CommandLineTools.bundled%")
If you use DotCover with custom path (for example, /custom/path
), then the result should look like this:
param("dotNetCoverage.tool", "dotcover")
param("dotNetCoverage.dotCover.home.path", "/custom/path")
If you use a typed maven DSL without raw parameters, then this change should not affect you, because typed DSL generates up\-to\-date settings.
If you specify maven build runner settings via the param("name", "value")
method, then parameters need to be updated. The easiest way to update settings is to switch to the typed DSL: you can generate settings in the Kotlin format to see what the typed DSL for Maven looks like.
If you want to continue using the param("name", "value")
method, do the following:
rename the
mavenSelection
parameter tomaven.path
, change its old value to the new one:
Old value to be changed | New value |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
| value of the |
remove the
maven.home
parameter.
TeamCity 2017.1 adds support for cross\-platform PowerShell. Previously PowerShell builds used only the Desktop edition and were run only on Windows.
To ensure that the existing builds remain restricted to the Desktop edition of PowerShell, set the following property in the existing PowerShell steps:
edition = PowerShellStep.Edition.Desktop
or if you use raw parameters:
param("jetbrains_powershell_edition", "Desktop")
Thanks for your feedback!