TeamCity オンプレミス 2026.1 ヘルプ

DSL のアップグレード

TeamCity XML 設定形式は、通常、メジャーリリースで変更されます。サーバー更新後の最初の起動時に、TeamCity は TeamCity データディレクトリの XML 設定ファイルを新しい形式に変換します。設定が Kotlin DSL に保存されている場合、機能を維持するために Kotlin コードを変更する必要がある場合があります。また、Kotlin コードを最新の構成バージョンに更新することもお勧めします。

これらの推奨事項は、サーバー管理 UI の対応するページにサーバーヘルスレポートとして表示されます。

TeamCity 設定形式の変更

DSL に関する限り、次のタイプの TeamCity 設定の変更があります。

自動的に実行できる変更

これらのタイプの設定変更では、DSL から設定が再生成されるたびにサーバーによって変更が自動的に適用されるため、Kotlin DSL を変更する必要はありません。
ただし、パフォーマンスの低下を軽減し、Kotlin スクリプトを UI に表示される設定に近づけるために、DSL を新しい構成バージョンに更新することをお勧めします。

TeamCity 設定の多くの変更がこのカテゴリに分類されます。例: ビルドステップを実装する一部のプラグインでは、パラメーターの名前が変更されることがあります。
以前の TeamCity バージョンの DSL では古い名前のパラメーターが生成されますが、TeamCity では DSL 実行後に古いパラメーター名を新しいパラメーター名に自動的に置き換えることができます。

自動的に実行できない変更

一部の TeamCity 設定の変更には外部情報が必要であり、自動的に実行できません。例: TeamCity 10.0 では、クラウド統合の設定は、VCS にコミットされていない専用ファイルに保存されていました。TeamCity 2017.1 では、これらの設定はプロジェクトレベルに移動されました。TeamCity は、外部データがないとこのような設定の変換を自動的に実行できないため、手動で DSL コードを更新する必要があります。

DSL コードのバージョン

構成バージョン

これは settings.kts で指定されたバージョンで、次のようになります。

version = "2025.11"

TeamCity は、このバージョンを使用して DSL の実行後に変換を実行し、結果の XML 構成ファイルを、それらが適用される現在の TeamCity バージョンで最新のものにします。たとえば、DSL スクリプトを TeamCity 2017.2 で生成し、バージョンを 2017.2 に設定することができます。サーバーをバージョン 2022.04 にアップグレードすると、TeamCity は DSL を実行し、追加の変換を適用して、最新バージョンで期待される形式に従って設定を変更します。

Kotlin DSL API バージョン

2022.04 の前に TeamCity によって生成された DSL コードには、パッケージ名にエンコードされた DSL API バージョンがあります(例: jetbrains.buildServer.configs.kotlin.v2019_2)。そこにある v2019_2 部分は、この DSLAPI が導入されたときの TeamCity バージョンに対応しています。

DSL API に重大な互換性のない変更があった場合、新しい DSL API バージョンが導入されます。ただし、TeamCity 2019.2 以降は互換性のない変更はありませんでした。そのため、その後のいくつかの TeamCity バージョンでは、新しく生成された DSL コードに同じ v2019_2 パッケージ名が使用されていました。TeamCity 2022.04 以降では互換性のない変更がないため、DSL API バージョンは冗長であると見なされ、このバージョンを含まないパッケージへの切り替えを実行することをお勧めします。

アップグレード後のバージョン設定の有効化

バージョン管理された設定が Kotlin 形式で保存されている場合、TeamCity サーバーを新しいバージョンにアップグレードすると、DSL コードが機能し続けるように自動的に更新されるコンバーターが使用されます。

ただし、TeamCity は、これらの設定を XML 形式で保存するプロジェクトのバージョン設定をオフにする場合があります。この現象は、サーバーのアップグレードによって設定 XML ファイルが変更される場合に発生します。これは、TeamCity サーバーの非実稼働バージョンにアップグレードするときに、不要な構成の更新を防ぐように設計されています。

新しい TeamCity バージョンが安定しており、XML ファイルの更新を続行したい場合は、対応する正常性レポートアクションをクリックします。TeamCity は、更新された XML 設定ファイルを VCS にコミットします。このコミットには、バージョン管理された設定が無効になっている間に TeamCity UI 経由で行われたすべてのプロジェクト構成の更新も含まれます。

Kotlin DSL のアップグレード手順

通常、サーバーのアップグレード後、Kotlin DSL スクリプトはすぐに変更する必要はなく、新しい TeamCity バージョンでも同じ結果が得られるはずです。ただし、最新の構成バージョンを使用するように Kotlin DSL スクリプトを更新することをお勧めします。

Kotlin DSL スクリプトがリポジトリで変更され、これらの変更が失われない場合は、手動アップグレードをお勧めします。

手動 DSL スクリプトのアップグレード: 設定バージョンを変更する

settings.kts には、いわゆる configs バージョンが含まれています。

version = "2025.11"

このバージョンは、TeamCity サーバーの現在のバージョンに変更する必要があります。たとえば、TeamCity サーバーが 2025.11 にアップグレードされた場合、2025.11settings.kts で指定する必要があります。

ただし、その前に、DSL スクリプトに最新の変更を適用した後に TeamCity サーバーによって生成されたヘルスレポートを最初に確認する必要があります。これらのヘルスレポートには、構成バージョンを安全に変更する前に DSL にどのような変更を加える必要があるかが記述されています。

次のようなメッセージが表示された場合:

Please change the configs version to "%product-version%" in projects: <the list of projects>

DSL に追加の変更は必要ありません。構成の version2025.11 に変更できます。それ以外の場合、次のメッセージが表示されます。

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>

これらの提案を確認し、DSL スクリプトに適用する必要があります。これらの提案がすべて適用された後にのみ、構成バージョンを変更できます。

DSL を 2025.11.x から 2026.1.x に更新

バージョン 2026.1 では、Amazon および Web サービスと連携するすべての TeamCity プラグインが AWS SDK v2 をサポートするように更新されました。この変更は既存の連携に影響を与えず、大規模な手動更新も必要ありません。

注目すべきアップデートの一つは、アクセス制御リスト(ACL)名が、以前の PublicReadBucketOwnerFullControl に代わり、public-readbucket-owner-full-control といった対応する AWS 値と一致するようになったことです。これらの値は通常、アクセスポリシーを変更できる追加の storage.s3.acl パラメーターで使用されます。

DSL を 2025.07.x から 2025.11.x に更新

マトリックスビルド用の separateArtifactsgroupArtifactsByBuild に名前が変更されました。詳細は YouTrack チケット(TW-84334(英語))を参照してください。

DSL を 2025.03.x から 2025.07.x に更新

潜在的な破壊的な変更はありません。

DSL を 2024.12.x から 2025.03.x に更新

Docker サポート機能の名前が Docker レジストリ接続に変更されたため、Kotlin DSL 内の対応するエンティティの名前も変更されました。

// 2024.12 and older features { dockerSupport { cleanupPushedImages = true loginToRegistry = on { dockerRegistryId = "PROJECT_EXT_5" } } } // 2025.03 and newer features { dockerRegistryConnections { cleanupPushedImages = true loginToRegistry = on { dockerRegistryId = "PROJECT_EXT_5" } } }

古い構文を使用した既存の構成は引き続き機能し、ビルド機能の設定を変更した場合にのみ自動的に更新されます。この変更を反映するには、既存の構成ファイルを手動で更新することをお勧めします。

DSL を 2023.11.x から 2024.12.x に更新

  • バンドルされている Kotlin バージョンは 2.0.21 に更新されました。言語バージョンは 1.9 のままです。今後のリリースでは、K2 コンパイラーへの移行とともに言語バージョンを上げる予定です。この変更がカスタム Kotlin コードに影響するかどうかは、K2 移行ガイド(英語)を参照してください。

DSL を 2022.05.x から 2023.11.x に更新

  • バンドルされた Kotlin バージョンは 1.8.22 に更新されました。

  • セキュリティ上の理由から、既存の AWS 接続は、これらの接続を所有する TeamCity プロジェクトのみが使用できるようになりました。子サブプロジェクトは、親プロジェクトの接続にアクセスできません。サブプロジェクトが親プロジェクトの AWS 接続を使用できるようにするには、allowInSubProjects = true パラメーターをこの接続の設定ブロックに追加します。

DSL を 2022.10.x から 2023.05.x に更新

  • バンドルされた Kotlin バージョンは 1.7.10 に更新されました。

DSL を 2022.04.x から 2022.10.x に更新

  • Bitbucket サーバー / データセンターリポジトリをターゲットとするビルド構成のプルリクエストビルド機能は、公式にサポートされていないプルリクエストブランチを追跡しなくなりました (代わりにソースブランチを監視します)。以前の (非推奨の) 動作に手動で切り替えるには、usePullRequestBranches = true パラメーターをプルリクエスト機能に追加します。詳細については、TeamCity Kotlin DSL ドキュメントの記事 PullRequests を参照してください。

DSL を 2021.2.x から 2022.04.x に更新

  • バンドルされた Kotlin バージョンは 1.6.21 に更新されました。

  • パッケージ名にバージョンがない新しい DSLAPI アーティファクトが導入されました。これらの DSLAPI アーティファクトに切り替える方法を以下に示します。

DSLAPI パッケージ名からバージョンを削除する

TeamCity 2022.04 以降では、DSL コードのインポートのバージョン部分を削除して、DSL コードの外観を簡素化し、IntelliJ IDEA でのコード補完の提案を改善することをお勧めします。

例: インポート品:

import jetbrains.buildServer.configs.kotlin.v2019_2.* import jetbrains.buildServer.configs.kotlin.v2019_2.projectFeatures.*

次のように変更できます:

import jetbrains.buildServer.configs.kotlin.* import jetbrains.buildServer.configs.kotlin.projectFeatures.*

インポートされたパッケージ名から DSLAPI バージョンを削除するには、次の手順を実行する必要があります。

  1. pom.xml ファイルの <dependencies/> セクションを更新します

    ArtifactId configs-dsl-kotlinconfigs-dsl-kotlin-latest に変更し、configs-dsl-kotlin-pluginsconfigs-dsl-kotlin-plugins-latest に変更する必要があります

    最終的に、<dependencies/> セクションは次のようになります。

<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>
  1. TeamCity サーバーが稼働していることを確認してください。

    ID configs-dsl-kotlin-plugins-latest のアーティファクトは、TeamCity サーバーによって提供されます。これは、pom.xml の <repositories/> セクションで ID teamcity-server で指定されているものと同じ TeamCity サーバーです。Maven はアーティファクト configs-dsl-kotlin-plugins-latest をダウンロードできるはずなので、このサーバーは稼働している必要があります。

  2. すべての Kotlin ファイルのインポートを変更します。

    パッケージ名のバージョン部分は、すべての Kotlin ファイルで削除する必要があります。次に例を示します。

    import jetbrains.buildServer.configs.kotlin.v2019_2.*

    次のように置き換える必要があります:

    import jetbrains.buildServer.configs.kotlin.*

  3. DSL をコンパイルし、設定を生成します。

    pom.xml および Kotlin ファイルに変更を加えた後、mvn teamcity-configs:generate タスクを実行して、プロジェクトが引き続きコンパイルされることを確認することをお勧めします。エラーがない場合は、これらの変更をバージョン管理された設定リポジトリにチェックインできます。

DSL を 2021.1.x から 2021.2.x に更新

  • このリリースでは新しい DSL API パッケージは導入されていないため、v2019_2 が最新のもののままです。

  • バンドルされた Kotlin バージョンは 1.5.31 に更新されました。

  • 型付き DSL は、プロジェクトのさまざまな設定とビルド構成でサポートされるようになりました。ここで改善点の全リストを参照してください。

DSL を 2020.2.x から 2021.1.x に更新

  • このリリースでは新しい DSL API パッケージは導入されていないため、v2019_2 が最新のもののままです。

  • バンドルされた Kotlin バージョンは 1.4.32 に更新されました。

  • Git VCS ルートの useMirrors パラメーターは非推奨となり、次の値をサポートする checkoutPolicy パラメーターに置き換えられました。 AUTOUSE_MIRRORSNO_MIRRORSSHALLOW_CLONE .
    プロジェクト DSL コード内の Git VCS ルートは、それに応じて更新する必要があります。たとえば、useMirrors=falsecheckoutPolicy=NO_MIRRORS に置き換え、useMirrors=truecheckoutPolicy=USE_MIRRORS に置き換えます。Git VCS ルートで useMirrors が指定されていない場合は、checkoutPolicy=USE_MIRRORS を追加する必要があります。
    チェックアウトポリシーの詳細については、こちらを参照してください。

  • installToolPackage フィールドの Python ビルドステップのデフォルト値が変更されました。2021.1 以降、installToolPackage はデフォルトで true です。Python ビルドステップの現在の動作を維持するには、installToolPackage = false をビルドステップ設定に追加します。

DSL を 2020.1.x から 2020.2.x に更新

  • このリリースでは新しい DSL API パッケージは導入されていないため、v2019_2 が最新のもののままです。

  • バンドルされた Kotlin バージョンは 1.4.21 に更新されました。

DSL を 2019.2.x から 2020.1.x に更新

  • このリリースでは新しい DSL API パッケージは導入されていないため、v2019_2 が最新のもののままです。

  • バンドルされた Kotlin バージョンは 1.3.70 に更新されました。

DSL を 2019.1.x から 2019.2.x に更新

  • バンドルされた Kotlin バージョンは 1.3.60 に更新されました。

  • このリリースでは、新しい DSL API パッケージ v2019_2 が導入されています。このパッケージには、クリーンアップルール用の更新された API があり、Kotlin DSL スクリプト内で DSL コンテキストパラメーターの値を取得する機能を提供します。

DSL スクリプトのプロジェクトレポートタブ定義の更新

ReportTab プロジェクト機能のパラメーターを変更する必要があります。

  • revisionRuleName パラメーターの値が lastFinishedlastSuccessfullastPinned に設定されている場合は、revisionRuleRevision パラメーターを削除する必要があります。

  • パラメーター revisionRuleNamebuildNumber 値がある場合、revisionRuleRevision パラメーターの名前を revisionRuleBuildNumber に変更する必要があります。

  • パラメーター revisionRuleName の値が buildTag の場合、revisionRuleRevision パラメーターの名前を revisionRuleBuildTag に変更し、パラメーターの値から接尾辞 .tcbuildtag を削除する必要があります。

DslContext.baseDir

TeamCity 2019.2 以降、DslContext.baseDir プロパティを使用して、DSL スクリプトから .teamcity ディレクトリ下のファイルにアクセスします。例:

val dataFile = File(DslContext.baseDir, "data/setup.xml")

TeamCity 2019.2 は、DSL スクリプトの現在の作業ディレクトリが .teamcity ディレクトリであることを保証しなくなったため、これが必要です。

DSL を 2018.2.x から 2019.1.x に更新

このリリースでは、新しい DSL API バージョン v2019_1 が導入されましたが、バージョン 2018.2.x および 2019.1.x の間で DSL に大きな変更がなかったため、そのパッケージはまだ jetbrains.buildServer.configs.kotlin.v2018_2 です。

Maven ビルドステップの更新

DSL を生成する Maven ビルドステップを更新する必要があります。Maven ビルドステップの useOwnLocalRepo パラメーターが true に設定されていない場合、次の localRepoScope パラメーターを追加する必要があります。

maven { ... localRepoScope = MavenBuildStep.RepositoryScope.MAVEN_DEFAULT }

useOwnLocalRepotrue に設定されていた場合は、次のものに置き換える必要があります。

maven { ... localRepoScope = MavenBuildStep.RepositoryScope.BUILD_CONFIGURATION }

MSBuild および VS.Solution ビルドステップにバージョンを追加する

MSBuild または VS.Solution ビルドステップのパラメーター toolsVersionMSBuildStep.MSBuildToolsVersion.V15_0 に設定されている場合、追加の version = MSBuildStep.MSBuildVersion.V15_0 パラメーターを追加する必要があります。

msBuild { ... toolsVersion = MSBuildStep.MSBuildToolsVersion.V15_0 version = MSBuildStep.MSBuildVersion.V15_0 }

ビルド構成パラメーター buildDefaultBranch は非推奨です

ビルド構成バージョン管理設定パラメーター buildDefaultBranch は非推奨です: 代わりに branchFilter を使用する必要があります。
たとえば、buildDefaultBranchfalse に設定されている場合、代わりに次のブランチフィルターを指定する必要があります。

vcs { branchFilter = """ +:* -:<default> """ }

DSL を 2018.1.x から 2018.2.x に更新

このリリースでは、新しい DSL API バージョン v2018_2 が導入され、そのパッケージは jetbrains.buildServer.configs.kotlin.v2018_2 です。

DSL を 2017.2.x から 2018.1.x に更新

このリリースでは、新しい DSL API バージョン v2018_1 が導入され、そのパッケージは jetbrains.buildServer.configs.kotlin.v2018_1 です。以前の API バージョンは機能します。ポータブル DSL スクリプトを使用したくない場合は、引き続き使用できます。

Docker パラメーターの更新

Docker プラグイン構成用に TeamCity 2017.2 で Kotlin DSL を使用した場合、TeamCity 2018.1 と互換性のあるコードにするために、Kotlin 構成スクリプトでいくつかの変更を行う必要がある場合があります。

変更の本質:

  • ビルドステップ dockerBuilddockerCommand に変換されました

  • DockerBuild のパラメーターは、commandType セレクターのサブパラメーターになりました

違いに注意してください:

Docker ビルド 2 Docker コマンドの移行

# 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" } }

Docker プッシュコマンドのサポート

dockerCommand { name = "name of the push step" commandType = push { namesAndTags = "maxkir/maxkir_test" } }

Commit Status Publisher の Gerrit パブリッシャー設定にラベルプロパティを追加する

ステータス発行者のコミットビルド機能の TeamCity 2018.1 以降 Gerrit パブリッシャー設定により、ビルドステータスを反映する Gerrit ラベルをカスタマイズできます。つまり、確認済み以外のものを使用できるようになりました。

Kotlin DSL 設定を手動で変更するには、ラベル =「確認済み」ステートメントを次のように追加する必要があります。

features { ... commitStatusPublisher { publisher = gerrit { server = "<server>" gerritProject = "<project>" failureVote = "-1" successVote = "+1" userName = "<user>" uploadedKey = "<key>" label = "Verified" // the statement to be added } } ... }

DSL を 2017.1.x から 2017.2.x に更新

DSL バージョン

このリリースでは、新しい DSLAPI バージョン v2017_2 が導入されています。以前の API バージョンは機能し、新しい API によって提供される機能(英語)が必要ない場合は、引き続き使用できます。

2017.2 EAP を使用し、UI を介して DSL 設定の変更をテストした場合、一部の API は互換性のない方法で変更されるため、アップグレードする前に TeamCity によって作成されたすべての UI パッチを適用する必要があります。

TeamCity によって生成された設定の現在のパッケージ名は jetbrains.buildServer.configs.kotlin.v2017_2 です。

新しい API を使用すると、Kotlin DSL プロジェクトの編集可能な管理 UI や DSL ドキュメントなど、多くの新機能を利用(英語)できます。既存のプロジェクトで使用するには、.kt ファイルを v2017_2 version からパッケージに切り替える必要があります。

  • このプロジェクトをコンパイルするには、pom.xml も更新する必要があります。最も簡単な方法は、プロジェクトで「設定を Kotlin 形式でダウンロード」アクションを呼び出して、生成された zip アーカイブから pom.xml をコピーすることです。または、次のようにして pom.xml を自分で更新することもできます。

    • teamcity.dsl.version を変更: <teamcity.dsl.version>2017.2</teamcity.dsl.version>

    • kotlin のバージョンを変更します: <kotlin.version>1.1.4-3</kotlin.version> に kotlin\-runtime と 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>

プロジェクトを新しい API に切り替えて変更をチェックインすると、TeamCity がそれを検出して適用し、その後 Web UI の編集が有効になります。
既存の pom.xml を含むリポジトリで新しい DSL API を使用するには、maven 依存関係バージョンを 2017.2 に更新する必要があります。

Docker パラメーターの更新

Docker プラグイン構成用に TeamCity 2017.1 で Kotlin DSL を使用した場合、コードを TeamCity 2017.2 と互換性を持たせるために、kotlin 構成スクリプトでいくつかの変更を行う必要がある場合があります。基本的に、TeamCity は、これらの変更を自動的に実行する Kotlin 構成スクリプト用のコンバーターを提供しますが、何らかの理由で機能しない場合は、以下の変更を手動で行う必要があります。

  • ビルドランナーステップの名前を Docker ビルド runType から DockerBuild に変更します

  • ビルドランナーステップの名前を Docker Compose runType から DockerCompose に変更します

  • docker-compose.file ビルドパラメーターの名前を dockerCompose.file に変更します

TeamCity 2017.2 以降、Docker プラグインには、Docker レジストリ接続ビルド機能、コンテナーラッパーDockerDocker Compose ランナー用の独自の型付き DSL があります。

Docker Compose および Docker ビルド

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 ビルド機能

features { dockerSupport { cleanupPushedImages = true loginToRegistry = on { dockerRegistryId = "PROJECT_EXT_2" } } }

Container Wrapper を使用したコマンドラインランナー

script { scriptContent = "ls -lR" dockerImage = "openjdk:8u121" dockerPull = true dockerRunParameters = "--rm -v /some/path:/another/path:ro" }

デフォルトのプロジェクトテンプレートの更新

2017.2 EAP3 以降、TeamCity はプロジェクト内のデフォルトテンプレートをサポートしています。この設定は、EAP3 および EAP4 では「DefaultTemplate」タイプのプロジェクト機能に保存されていましたが、2017.2 RC 以降、プロジェクト構成スキーマが変更され、デフォルトテンプレートに対応できるようになりました。
デフォルトのテンプレートを使用する DSL プロジェクト構成を手動で変換するには、対応するプロジェクト機能を削除し、次のように defaultTemplate プロパティの割り当てに置き換える必要があります。

2017.2 デフォルトのテンプレートが設定された EAP3 / 4 DSL プロジェクトの設定:

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 プロジェクトの設定:

object Project : Project({ uuid = "2b241ffb-9019-4e60-9a3a-d5475ab1f312" extId = "ExampleProject" parentId = "_Root" name = "Example Project" defaultTemplate = "ExampleProject_MyDefaultTemplate" ... features { ... } ... })

.NET CLI パラメーターの更新

2017.2 以降、TeamCity は .NET CLI プラグインをバンドルしていました(現在は .NET ランナーとして再導入されています)。TeamCity 2017.1.x のプラグインパラメーターに Kotlin DSL を使用していた場合は、コマンドを次のように変更する必要があります。TeamCity 2017.1.x の場合:

steps { step { type = "dotnet" param("dotnet-command", "build") param("dotnet-paths", "WindowsAzure.sln") } }

TeamCity 2017.2 以降、パラメーターを使用してビルドステップを明示的に指定できます。

steps { dotnetBuild { projects = "WindowsAzure.sln" } }

共通パラメーター

2017.1

2017.2

コメント

dotnet\- コマンド

dotnet <コマンド>

これで、コマンド名はビルドステップ名を反映します。dotnetRestore

ドットネット \-args

args

dotnet\-verbosity

logging

dotnet build

2017.1

2017.2

コメント

ドットネットパス

projects

ドットネット \- ビルド \-config

configuration

dotnet\-build\-framework

framework

dotnet\-build\- 出力

outputDir

dotnet\-build\-runtime

runtime

dotnet\-build\-no\-deps

\-

--no-dependencies 引数として追加する必要があります

dotnet\-build\-not\-incremental

\-

--no-incremental 引数として追加する必要があります

dotnet clean

2017.1

2017.2

ドットネットパス

projects

dotnet\-clean\-config

configuration

dotnet\-clean\-framework

framework

dotnet\-clean\- 出力

outputDir

dotnet\-clean\-runtime

runtime

dotnet msbuild

2017.1

2017.2

ドットネットパス

projects

ドットネット \-msbuild\-config

configuration

dotnet\-msbuild\- プラットフォーム

platform

dotnet\-msbuild\- ターゲット

targets

dotnet\-msbuild\-runtime

runtime

dotnet nuget delete

2017.1

2017.2

dotnet\-nuget\-delete\-id

packageId

dotnet\-nuget\-push\-source/

dotnet\-nuget\-delete\-source

packageSource

セキュア: dotnet\-nuget\-delete\-api\-key

apiKey

dotnet nuget push

2017.1

2017.2

コメント

ドットネットパス

packages

dotnet\-nuget\-push\-source

packageSource

dotnet\-nuget\-push\-no\-symbols

noSymbols

セキュア: dotnet\-nuget\-push\-api\-key

outputDir

dotnet\-build\-runtime

apiKey

dotnet\-nuget\-push\-no\-buffer

\-

--disable-buffering true 引数として追加する必要があります

dotnet pack

2017.1

2017.2

コメント

ドットネットパス

projects

ドットネット \- パック \-config

configuration

dotnet\-pack\-runtime

runtime

dotnet\-pack\-no\-build

skipBuild

dotnet\-pack\- 出力

outputDir

dotnet\-pack\-version\-suffix

versionSuffix

dotnet\-pack\-serviceable

\-

--serviceable 引数として追加する必要があります

dotnet publish

2017.1

2017.2

ドットネットパス

projects

dotnet\-publish\-config

configuration

dotnet\-publish\-framework

framework

dotnet\-publish\- 出力

outputDir

dotnet\-publish\-runtime

runtime

dotnet\-publish\-version\-suffix

versionSuffix

dotnet restore

2017.1

2017.2

コメント

ドットネットパス

projects

ドットネット \- 復元 \-config

configFile

dotnet\-restore\-runtime

runtime

dotnet\-restore\- パッケージ

packagesDir

dotnet\-restore\-source

packageSources

dotnet\-restore\-ignore\-failed

\-

--ignore-failed-sources 引数として追加する必要があります

dotnet\-restore\-no\-cache

\-

--no-cache 引数として追加する必要があります

dotnet\-restore\-parallel

\-

--disable-parallel 引数として追加する必要があります

dotnet\-restore\-root\-project

\-

--no-dependencies 引数として追加する必要があります

dotnet run

2017.1

2017.2

ドットネットパス

projects

ドットネット実行 -config

configuration

dotnet\-run\-framework

framework

ドットネット \-run\-runtime

runtime

dotnet test

2017.1

2017.2

ドットネットパス

projects

ドットネット \- テスト \-config

configuration

dotnet\-test\-framework

framework

dotnet\-test\-no\-build

skipBuild

dotnet\-test\- 出力

outputDir

dotnet\-test\-settings\- ファイル

settingsFile

dotnet\-test\-runtime

runtime

dotnet\-test\-test\-case\-filter

filter

dotnet vstest

2017.1

2017.2

コメント

ドットネットパス

assemblies

dotnet\-vstest\-config\- ファイル

settingsFile

dotnet\-vstest\-framework

framework

dotnet\-vstest\- プラットフォーム

platform

dotnet\-vstest\-filter\-type

filter

テストを名前でフィルタリングするには、name { names = "..." } を使用します。テストケースフィルターには、filter { filter = "..." } を使用します

dotnet\-vstest\-is\-isolation

\-

/InIsolation 引数として追加する必要があります

DSL を 10.0.x から 2017.1.x に更新

TeamCity 2017.1 は、新しい Kotlin DSL API を導入しません。TeamCity 10.0.x と同じパッケージが使用されます(jetbrains.buildServer.configs.kotlin.v10)。既存の API にいくつかの新しいプロパティが追加されます。スクリプト開発用の最新の API を取得するには、pom.xmlteamcity.dsl.version を EAP ビルドの場合は 2017.1-SNAPSHOT に、リリースビルドの場合は 2017.1 に更新します。

Kotlin DSL スクリプトの手動更新が必要な変更

これらの変更は、「TeamCity のアップグレード中に設定ファイルが変更されたため、このプロジェクトではバージョン設定が無効になっています」というメッセージで TeamCity アップグレードで無効にされたプロジェクトでバージョン設定を有効にする前に実行する必要があります。

クラウドプロファイルの変換

これは、ルートプロジェクト設定に Kotlin DSL を使用し、クラウドプロファイルがある場合にのみ関連します。
2017.1 では、クラウドプロファイルはサーバーレベルからルートプロジェクトレベルに移動されました。これらは Kotlin DSL で定義されていないため、バージョン設定を有効にすると、既存のクラウドプロファイルはサーバーから削除されます。サーバー上のルートプロジェクトに Kotlin DSL を引き続き使用する前に、Kotlin DSL のルートプロジェクト設定にクラウドプロファイル定義を追加してください。

クラウドプロファイル情報で設定を更新するには、次を実行します。

  1. ルートプロジェクトで 'Kotlin 形式で設定をダウンロード ' アクションを実行し、生成された DSL で zip を保存します。

  2. タイプ CloudIntegration および CloudProfile のプロジェクト機能を .teamcity/_Root/Project.kt ファイルから設定のルートプロジェクト構成にコピーします。

  3. VCS への変更をコミットします。

  4. ルートプロジェクトのバージョン対応設定タブでバージョン設定を有効にします。

エンティティの名前

発行 TW-48609(英語) の修正により、設定に名前のないエンティティが含まれている場合、TeamCity は対応する VCS 設定エラーを報告します。エラーを解決するには、そのようなエンティティに名前パラメーターを手動で設定する必要があります。

Kotlin DSL 構成バージョンを 10.0 から 2017.1 に更新する

このセクションの変更は、スクリプトの設定バージョンを 10.0 から 2017.1 に変更するときに、Kotlin スクリプトに対して行う必要があります。

DotCover パラメーターの更新

DotCover で使用されるパラメーターが変更されました。使用する場合は、dotNetCoverage.tooldotcover 値があることを確認してください。dotNetCoverage.dotCover.home.path パラメーターが欠落している場合は、%teamcity.tool.JetBrains.dotCover.CommandLineTools.bundled% に設定します。結果は次のようになります。

param("dotNetCoverage.tool", "dotcover") param("dotNetCoverage.dotCover.home.path", "%\teamcity.tool.JetBrains.dotCover.CommandLineTools.bundled%")

カスタムパス(/custom/path など)で DotCover を使用する場合、結果は次のようになります。

param("dotNetCoverage.tool", "dotcover") param("dotNetCoverage.dotCover.home.path", "/custom/path")

Maven ビルドステップパラメーターの更新

生のパラメーターなしで型指定された maven DSL を使用する場合、型指定された DSL によって最新の設定が生成されるため、この変更による影響はありません。

param("name", "value") メソッドを介して maven ビルドランナー設定を指定する場合、パラメーターを更新する必要があります。設定を更新する最も簡単な方法は、型付き DSL に切り替えることです。Kotlin 形式で設定を生成して、Maven 用の型付き DSL がどのように見えるかを確認できます。

param("name", "value") メソッドを引き続き使用する場合は、次の手順を実行します。

  • mavenSelection パラメーターの名前を maven.path に変更し、古い値を新しい値に変更します。

変更する古い値

新しい値

mavenSelection:bundledM2

%teamcity.tool.maven%

mavenSelection:bundledM3_0

%teamcity.tool.maven3%

mavenSelection:bundledM3_1

%teamcity.tool.maven3_1%

mavenSelection:bundledM3_2

%teamcity.tool.maven3_2%

mavenSelection:bundledM3_3

%teamcity.tool.maven3_3%

mavenSelection:default

%teamcity.tool.maven.AUTO%

mavenSelection:custom

maven.home パラメーターの値

  • maven.home パラメーターを削除します。

PowerShell ビルドステップパラメーターの更新

TeamCity 2017.1 は、クロスプラットフォームの PowerShell のサポートを追加します。以前の PowerShell ビルドでは、デスクトップエディションのみが使用され、Windows でのみ実行されていました。

既存のビルドが PowerShell のデスクトップエディションに制限されたままになるようにするには、既存の PowerShell ステップで次のプロパティを設定します。

edition = PowerShellStep.Edition.Desktop

または、生のパラメーターを使用する場合:

param("jetbrains_powershell_edition", "Desktop")
2026 年 5 月 05 日

関連ページ:

バージョン管理でのプロジェクト設定の保存

TeamCity では、プロジェクト設定をバージョン管理リポジトリ(VCS)と同期できます。サポートされている VCS は、Git、Mercurial、Perforce、Subversion、Azure DevOps Server(旧 TFS)です。プロジェクト設定を XML 形式または Kotlin 言語で保存し、Kotlin ベースの DSL を使用してプログラムで設定を定義できます。重要なポイント:この機能は何をしますか ? 個々のプロジェクトの設定を XML または Kotlin 形式でリモ...

Docker レジストリ接続

Docker レジストリ接続ビルド機能により、TeamCity はビルドの開始前に DockerHub またはその他のコンテナーレジストリに自動的にサインインできます。この機能を次の場所に追加します。TeamCity による Docker/Podman 操作 (たとえば、および) の監視と検出を許可します。ビルド前に認証されたレジストリに自動的にログインし、ビルド後にログアウトします。ローカル (Docker と Podman の両方) イメージをクリーンアップし、レジストリにプッシュ (Doc...

プルリクエスト

プルリクエストビルド機能は、GitHub、Bitbucket サーバー、Bitbucket クラウド、GitLab、Azure DevOps、JetBrains Space リポジトリのプル (マージ) リクエストとの TeamCity 統合を強化します。共通情報:ビルド構成にプルリクエスト機能を追加すると、次のことが可能になります。ビルド構成の概要ページで、プルリクエストブランチと保留中の変更を表示します。

Git

TeamCity は、Git をすぐにサポートします。Azure DevOps Services を使用した Git ソース管理がサポートされています (以下の認証に関する注意事項を参照)。このページには、VCS ルート設定の Git 固有のフィールドの説明が含まれています。一般的な VCS ルートプロパティについては、このセクションを参照してください。注意事項: リモート実行とテスト済みのコミットは IntelliJ IDEA プラグインでサポートされています。Visual Studio アドインで...

Kotlin DSL

TeamCity では、バージョン管理で設定を XML 形式で保存するだけでなく、DSL (Kotlin 言語に基づく) で設定を保存することもできます。バージョン管理に保存された DSL を使用すると、プログラムで設定を定義できます。Kotlin は静的に型指定されるため、IDE で自動補完機能を自動的に受け取ります。これにより、利用可能な API オプションの発見がはるかに簡単になります。TeamCity での Kotlin DSL の使用に関するブログ投稿シリーズと推奨リファクタリングの記...

ステータス発行者のコミット

Commit Status Publisher is abuild featurethat posts build statuses to the VCS provider. This allows you to track the code health from the repository page, and quickly navigate to related TeamCity builds to inspect detailed build logs.Supported VCS pr...