TeamCity 2020.2 ヘルプ

アップグレードノート

2020.2.1 から 2020.2.2 への変更

IntelliJ プラットフォームの互換性

IntelliJ IDEA バージョン 2019.2 以前、および IntelliJ プラットフォームバージョン 193 より前にリリースされた他の IntelliJ ベースの製品は、IntelliJ プラットフォームプラグインではサポートされなくなりました。詳細については、バージョン互換性の表を参照してください。

付属ツールのアップデート

  • TeamCity DSL で使用されていた Kotlin は、バージョン 1.4.21 に更新されました。

その他の更新

  • teamcity.tests.recentlyFailedTests.file システムプロパティには、最近失敗したテストを含むファイルへのフルパスが含まれており、カスタムビルドランナーでリスクテスト(英語)並べ替えるため(英語)に使用できます。以前は、常にデフォルトで生成されていました。現在、使用されているビルドランナーがテスト実行を並べ替えるように設定されている場合、または teamcity.internal.tests.provide.recentlyFailedTests パラメーターが true に設定されている場合にのみ提供されます。

2020.2 から 2020.2.1 への変更

既知の問題

  • TeamCity サーバーの Windows Docker イメージでは、UI からサーバーを再起動することはできません。コマンドラインからサーバー停止および起動する方法を参照してください。

TeamCity サーバーの Linux Docker イメージの重大な変更: デフォルトでは root 以外のユーザー

エージェント Docker イメージLinux 用の TeamCity サーバー Docker イメージは、デフォルトで非 root ユーザーで実行されるようになりましたに適用したセキュリティ慣行に従います。

デフォルトのユーザーで Linux イメージを実行しようとすると、「 Permissiondenied 」エラーが発生します。これを防ぐには、ホストデータディレクトリの所有権を変更する必要があります。必要なボリュームに適用された chown -R 1000:1000 を実行します。大きなディレクトリの場合、この操作には時間がかかり、ディスクのパフォーマンスが低下する可能性があります
または、-u 0 パラメーターを docker run コマンドに渡すことにより、root ユーザーでコンテナーを開始することもできます。これは、ディレクトリの所有権を変更する時間を節約できる簡単な回避策です。ただし、長期的には chown アプローチに固執することをお勧めします。

dotnetrun コマンドラインパラメーターの自動プレフィックスはありません

このバージョン以降、.NET ビルドランナー dotnet run パラメーターの前に -- を適用しません。以前は、ランナーがこのプレフィックスを自動的に追加していたため、カスタムオプションを run コマンドに渡すことができませんでした。これを修正するために、以前の動作を無効にしました。
残念ながら、影響を受ける .NET ビルドステップは、アップグレード時に自動的に変換できません。ステップのいずれかが実行中の .NET アプリケーションに引数を渡す場合は、必ずこれらのステップを変更し、それぞれのパラメーターの前に -- を付けてください。

付属ツールのアップデート

  • バンドルされている Tomcat がバージョン 8.5.61 に更新されました。

  • バンドルされている JaCoCo バージョンが 0.8.6 に更新されました。

2020.1.x から 2020.2 への変更

既知の問題

  • OptimizeAndCleanupIdsGroupsTableConverter のエラーでアップグレードが失敗した場合は、この問題(英語)で説明されている回避策を適用してください。

  • TeamCity エージェント latest タグ付きの Docker イメージは、Docker をバンドルしません。
    TeamCity 2020.2 エージェントで Docker を実行できるようにするには、代わりに {TEAMCITY_VERSION}-linux-sudo タグを付けた teamcity-agent イメージをダウンロードしてください。詳細については、Docker Hub ドキュメント(英語)を参照してください。

デフォルトの新しいヘッダー

新しいヘッダーは、従来の UI と実験的な UI の両方で有効になっています。以前のヘッダー用に開発された一部のプラグインは、新しいプラグインでは機能しない可能性があります。新しい API(英語) を使用すると、カスタムプラグインを新しいヘッダーと互換性のあるものにしたり、最新の Web テクノロジーを使用して新しいプラグインを作成したりできます。

このヘッダーに貴重な情報やアクションを表示するのに問題があり、プラグインの更新が便利なオプションではない場合は、teamcity.ui.useClassicHeader=true 内部プロパティを設定できます。これにより、TeamCity ヘッダーが前のビューに切り替わります。将来のバージョンで廃止されたヘッダーを無効にする可能性があるため、これは推奨される解決策ではないことに注意してください。

ビルド検索のインデックスの再作成

TeamCity 検索の Lucene バージョンが 8.5.1 に更新されました。アップグレード時に、TeamCity はサーバー上のすべてのビルドのインデックスを再作成します。これには時間がかかり、CPU に負荷がかかる可能性があります。インデックスの再作成中に、一部のビルドが検索結果に表示されない場合があります。

バンドルされた Python ランナー

外部 Python ビルドランナー(英語)はサポートされなくなりました。既存のすべてのビルドステップは引き続き正常に機能しますが、既存の Python ステップを新しいバンドルランナーに切り替えることをお勧めします。

Gradle の更新

  • 以前は、Gradle ランナーのビルドファイルフィールドはデフォルトで build.gradle に設定されていました。一部のユーザーはビルドファイルのカスタム名に依存しており、Gradle に選択するファイルを決定させることを好むため、このデフォルト値を削除しました。
    Gradle ステップでビルドファイルとして build.gradle が選択された場合、この設定はそのまま残ります。設定が VCS に保存されているプロジェクトでは、TeamCity はそれぞれの変更をコミットするように要求するため、バージョン管理されたプロジェクト設定で build.gradle プロパティが明示的に指定されます。

  • Gradle ランナーは、それぞれのテストメソッドに割り当てられた displayName プロパティに基づいてテスト名を表示するようになりました。Gradle テストにカスタム displayName プロパティのアノテーションが付けられている場合(たとえば、@DisplayName アノテーションの付いた JUnit 5 テスト)、アップグレード時に TeamCity でそれらの名前が変更されます。これにより、それぞれのビルドのテストと調査の履歴が破損する可能性があります。これを防ぐには、teamcity.internal.gradle.testNameFormat=name 内部プロパティを使用して動作を元に戻すことを検討してください。

セカンダリノードの新しい責任

バージョン 2019.2 以降、セカンダリノードは、少なくとも 1 つの責任が割り当てられている場合、ユーザーアクションを許可します。2020.2 では、「データを変更するためのユーザー要求の処理」という新しい責任が追加されます。この責任を持つノードは、現在サポートされているすべてのユーザーアクションを処理し、プロジェクト設定を変更できます。これがないと、ノードは読み取り専用インターフェースを提供します。
アップグレード時に、この責任は、少なくとも 1 つの他の責任を持つすべてのセカンダリノードで自動的に有効になります。これにより、これらのノードの現在の機能が影響を受けないことが保証されます。新しいセカンダリノードでのユーザーアクションを許可するには、管理 | サーバー構成で新しい責任を手動で有効にする必要があります。

同梱ツールの更新

  • TeamCity サーバーおよびエージェント Docker イメージ(Windows と Linux の両方)の .NET がバージョン 3.1.403 に更新されました。

  • TeamCity の Java Docker イメージが更新されました。
    • Windows サーバーイメージの場合: Amazon Corretto x64v.11.0.9.11.2 へ

    • Linux サーバーイメージの場合: Amazon Corretto x64v.11.0.9.11 へ。

    • Windows および Linux エージェントイメージの場合: Amazon Corretto x64v.8.272.10.3 へ

  • TeamCity サーバーおよびエージェントの Windows インストーラーにバンドルされている Java がバージョン 11.0.9.11.2 に更新されました。

  • バンドルされている Tomcat がバージョン 8.5.57 に更新されました。

  • TeamCity サーバー Docker コンテナー内の SACWindows イメージがバージョン 2004 に更新されました。WindowsLTS バージョンは TeamCity 2020.1 と同様に 1809 です。

  • TeamCity サーバー Docker コンテナーの Linux イメージがバージョン 20.04(LTS)に更新されました。

  • バンドルされた dotCover および ReSharper CLT は、バージョン 2020.2.4 にアップグレードされました。

  • 非推奨の Visual Studio2003 ビルドランナーは TeamCity で無効になっています。代わりに .NET ランナーを使用することをお勧めします。
    VS 2003 ランナーを積極的に使用していて、.NET ランナーに簡単に移行できない場合は、フィードバックチャネル(英語)のいずれかを介してお知らせください。

  • TeamCity の新規インストールで推奨される外部データベース用の JDBC ドライバーは、次のバージョンに更新されました。
    • MySQL - 8.0.22

    • MSSQL - 8.4.1

    • PostgreSQL - 42.2.18

その他の更新

  • GitHub の問題を検出するときに、TeamCity は、問題が割り当てられていないプル要求を除外するようになりました。このような独立したプルリクエストを発行ログに表示する必要がある場合は、teamcity.issues.github.filter.pull.requests=false 内部プロパティを設定することでこのフィルターを無効にできます。

  • メール通知は、現在の TeamCity サーバーの JVM でサポートされているものと同じバージョンの TLS プロトコルを使用するようになりました。

2020.1.4 から 2020.1.5 への変更

注目すべき更新はありません。

2020.1.3 から 2020.1.4 への変更

付属ツールのアップデート

  • バンドルされた Amazon Corretto Java は、TeamCity サーバーインストーラーおよび Docker イメージでバージョン 11.0.8 に更新されました。

  • バージョン 2020.1.2 で削除された Mercurial は、Windows Server Core エージェントの Docker イメージで再びサポートされます。

2020.1.2 から 2020.1.3 への変更

  • .NET ビルドランナーは、以前のバージョンの Visual Studio および MSBuild をサポートするようになりました。現在サポートされているバージョンは、Visual Studio 2010 以降、MSBuild 4 / 12 以降です。

既知の問題

  • アーティファクトの依存関係があるが、別のビルドへのスナップショットの依存関係がないビルドを再実行しようとすると、ビルド再実行ダイアログは読み込まれません。
    この問題は TeamCity 2020.1.4 で修正される予定です。バージョン 2020.1.3 で回避するには、次の手順(英語)に従ってください(英語)

2020.1.1 から 2020.1.2 への変更

  • Windows ServerCore エージェントの Docker イメージの Mercurial サポートは終了しました。Windows Server Core エージェントで Mercurial を使用する必要がある場合は、以前のバージョンのエージェント Docker イメージである 2020.1.1 をプルすることを検討してください。

2020.1 から 2020.1.1 への変更

  • .NET ランナーには、カスタムコマンドオプションが導入されています。カスタム .NET コマンドを構成した後で TeamCity を以前のバージョンにダウングレードすると、ビルド中にそれぞれのビルドステップが無視されることに注意してください。

  • TeamCity サーバーおよびエージェント Docker イメージで使用される Linux バージョンは、4.19.76-linuxkit に更新されました。

既知の問題

  • TeamCity クラシック UI では、ヘッダーのプロジェクトリンクに展開ボタンがありません。
    この問題を回避するには、ここで説明されている手順に従ってください。

2019.2.x から 2020.1 への変更

既知の問題

Jira クラウド統合ビルド機能には特定の VCS URL が必要

新しい Jira クラウド統合ビルド機能で使用される Jira クラウド API では、サーバー URL を特定の形式で送信する必要があります。そのため、ビルド機能は、Perforce、TFS、SVN などの VCS をそのままではサポートしていません。

この問題に対処するために、責任のあるプラグインを更新しました。トラッカーで関連する問題(英語)に添付されています。修正されたプラグインをダウンロードして、ここで説明されているようにインストールしてください
バンドルされている Jira クラウドプラグインは、次のリリースでこの修正により自動的に更新されます。

この機能は、Jira CloudAPI で期待される形式に対応しない一部の Git パスの解決にも失敗する可能性があります。この場合、URL を手動で変更するか(たとえば、git@<vcs_address>:<workspace_ID>/<repo_name>.git から ssh://git@<vcs_address>/<workspace_ID>/<repo_name>.git に)、上記のように固定プラグインをダウンロードすることができます。

Jira クラウド統合機能はレガシー Jira クラウドドメインをサポートしていません

現在、新しい Jira クラウド統合ビルド機能は atlassian.net ドメインのみをサポートしています。担当プラグインの修正バージョンに、レガシー jira.com ドメインのサポートを追加しました。Jira クラウドサーバーが jira.com ドメインにある場合は、関連する問題(英語)に添付されているプラグインをダウンロードして、ここで説明されているようにインストールできます。
バンドルされている Jira クラウドプラグインは、次のリリースでこの修正により自動的に更新されます。

Slack での認証時の不正なリダイレクト URI エラー

TeamCity から Slack にサインインできるようにするには、Slack アプリ設定で TeamCity サーバーのすべての可能な URI をリダイレクト URL として指定する必要があります。
nginx を使用してプロキシサーバーの背後で TeamCity をセットアップする場合、Slack との接続を確立しようとすると、bad_redirect_uri エラーが発生する可能性があります。このエラーは、nginx と Tomcat の構成の不一致が原因で発生します。

この問題を回避するには、関連する問題(英語)に添付されている修正済みプラグインをダウンロードし、ここで説明されているようにインストールします。または、Tomcat 設定を更新しててください
バンドルされている Slack プラグインは、次のリリースでこの修正により自動的に更新されます。

アップグレードされた 2020.1 EAP1 インストールの組み込み認証の問題

早期アクセスプログラムの観点から 2020.1 EAP1 ビルドをインストールした場合、組み込み認証を介した TeamCity へのサインインで問題が発生する可能性があります。この問題は、2020.1 EAP バージョン(EAP1 またはそれ以降にアップグレードされたバージョン)からリリース 2020.1 ビルドにアップグレードした後に発生する可能性があります。

この問題を回避するには、次のクエリを TeamCity データベースに送信してください。

UPDATE users SET algorithm = 'BCRYPT' WHERE password like '$2a$07$%' and algorithm = 'MD5';

サーバーおよびエージェントでの Java サポートの変更

  • Java 11 は、Java 8. ではなく、TeamCity サーバー Windows インストーラーおよびサーバー Docker イメージにバンドルされています。

  • TeamCity エージェントは、8 より前のバージョンの Java のサポートを停止します。いずれかのエージェントが以前のバージョンの Java で実行されている場合は、JRE をアップグレードして、これらのエージェントでビルドを引き続き実行できるようにしてください。

環境の新しい形式。JDK_ 環境変数

現在および将来の Java バージョンとの整合性を高めるために、env.JDK_ 環境変数の新しい形式を導入しました。
2020.1 以降、形式は次のとおりです: env.JDK_<major>_<minor>[_x64] 例: env.JDK_1_6env.JDK_1_7env.JDK_1_8env_JDK_11_0_x64
このように、かなり古い Java 1.4 を使用している場合、適切な変数は env.JDK_1_4 ですが、env.JDK_14_0 は Java 14.0. に使用されます。

下位互換性のために、env.JDK_16env.JDK_18 などの以前の環境変数も生成されますが、これらの変数は TeamCity 自動補完ポップアップメニューに表示されなくなります。ビルドスクリプトでこれらの環境変数を使用している場合は、新しい形式に移行することをお勧めします。

関連する問題(英語)を参照してください。

プラグインの再コンパイルが必要

一部のビルドランナーを実装するプラグインは、再コンパイル / アップグレードが必要になる場合があります。

対応するカスタムビルドランナーの新しいビルドステップが作成または更新されると、対応するエラーは java.lang.NoSuchMethodError: jetbrains.buildServer.controllers.admin.projects.BuildRunnerBean.getPropertiesBean のようになります。

Checkmarx プラグイン(英語)および SonarQube Runner プラグイン(英語)に関する関連問題を参照してください。

エージェント Docker イメージは非 root ユーザーで実行されます

推奨されるセキュリティプラクティスに準拠するために、TeamCity エージェントの Docker イメージが非 root ユーザーで実行されるようになりました。

この変更は、次のユースケースに影響を与える可能性があります。

  • 標準の TeamCity エージェントイメージに基づいてカスタムイメージを作成 / 更新するには、最初に root ユーザーに切り替える必要がある場合があります(詳細については、関連する問題(英語)を参照してください)。

  • ホストディレクトリをコンテナーにマウントすると、「アクセスが拒否されました」というエラーが発生する場合があります。この問題を防ぐには、次の回避策のいずれかを試してください。
    • chown コマンドを使用して、ディレクトリの所有者の UID を 1000 に設定します。

    • docker run コマンドで --user 引数を送信して、ホストマシンと同じ UID を Docker ユーザーに設定します。例: docker run -it --user $(id -u) ... を使用します。

    • TeamCity は書き込み可能なディレクトリのボリュームを自動的に作成し、通常は明示的にマッピングする必要がないことに注意してください。権限の問題を防ぐために、明示的な参照を省略することを検討してください。

非推奨の Windows トレイ通知機能

TeamCity Windows Tray Notifier は、新しい Browser Notifier 拡張機能のために廃止されました。

Windows Tray Notifier は TeamCity の新しいバージョンで引き続き機能しますが、代わりに新しい拡張機能を試すことをお勧めします。バージョン 2020.1 以降、TeamCity の設定とツール | 通知ルール | Windows トレイ通知機能タブの名前がブラウザー通知機能に変更されていることに注意してください。

バンドルされた Kubernetes サポートプラグインには Helm ランナーが含まれていません

Kubernetes サポートプラグイン(英語)は TeamCity にバンドルされます。アップグレード時に、TeamCity サーバーにインストールされている場合は、外部プラグインが置き換えられます。バンドルされているプラグインには Helm ビルドランナーが含まれていないことに注意してください。ビルド構成でこのランナーを引き続き使用するには、新しい外部プラグイン(英語)をインストールしてください。

書き込み操作に対する CORS サポートの制限

TeamCity は、CSRF トークンを導入することにより、RESTAPI 統合メカニズムのセキュリティを向上させます。この変更は、書き込み操作でクロスオリジンリソースシェアリング(CORS)に依存し、TeamCity で rest.cors.origins 内部プロパティが有効になっていない限り(デフォルトでは無効になっています)、カスタム統合スクリプトの動作に影響を与えません。

以前は、CSRF 保護は、HTTP リクエストの Origin/Referer ヘッダーの検証とともに TeamCity で提供されていました。TeamCity CSRF 保護を改善するために、この方法は無効にされ、より安全な方法である CSRF トークンが採用されます。このリリース以降、TeamCity は POST/PUT/DELETE RESTAPI リクエストの CORS メカニズムのサポートを停止します。クロスオリジン GET リクエストのヘッダーは以前と同じように処理されますが、CORS 設定が必要です。

必要に応じて、teamcity.csrf.paranoid=false 内部プロパティを設定することにより、CORS 操作を書き込むための Origin/Referer ヘッダーの検証を強制できます。これは一時的で安全性の低いソリューションであることに注意してください。既存のリクエストをリファクタリングして、新しいセキュリティポリシーに準拠し、CSRF ヘッダーまたはパラメーター内にトークンを提供することを強くお勧めします。CSRF トークンは、GET https://your-server/authenticationTest.html?csrf リクエストを介して取得でき、X-TC-CSRF-Token HTTP ヘッダーを介して CORS リクエストの書き込みに提供されます。

付属ツールのアップデート

  • バンドルされた IntelliJ IDEA がバージョン 2020.1.1 に更新されました。

  • バンドルされた Ant がバージョン 1.9.14 に更新されました。

  • バンドルされた Tomcat がバージョン 8.5.54 に更新されました。

  • バンドルされた Maven がバージョン 3.6.3 に更新されました。

  • TeamCity DSL で使用されている Kotlin は、バージョン 1.3.70 に更新されました。

  • TeamCity の新規インストールで推奨される外部データベース用の JDBC ドライバーは、次のバージョンに更新されました。
    • MySQL - 8.0.20

    • MSSQL - 8.2.2

    • PostgreSQL - 42.2.12

REST API の変更

ブランチ(.../app/rest/testOccurrences?locator=branch(XXX) リクエスト)によるテスト発生のフィルタリングが変更されました。以前は、大文字と小文字を区別するマッチングでブランチ名のみをサポートしていました。現在、XXX 値はブランチロケーターをサポートしています(ビルドのフィルタリング時と同じ)。デフォルトでは大文字と小文字が区別されず、<default> ブランチ表示名と一致します。

その他の変更点

  • 現在、このロールに現在のユーザーのロールよりも多くの権限がある場合、ユーザーは別のユーザーにロールを割り当てることができません。
    2020.1 にアップグレードした後、ユーザーが特定のロールを使用できないという問題が発生した場合は、これらのロールに、それぞれのプロジェクト管理者の権限を超える権限が含まれていないことを確認してください。

  • TeamCity は Internet Explorer のサポートを終了しました。代わりに Microsoft Edge を使用してください。

  • このバージョン以降、TeamCity 2019.2.3 で導入された新しい .NET ランナーは、廃止された外部 .NET CLI サポート(英語)プラグイン(バージョン 2017.1 以前で使用)と互換性がありません。以前にこのプラグインをインストールしたことがある場合は、サーバーからアンインストールして、新しい .NET ランナーを使用できるようにしてください。

2019.2.3 から 2019.2.4 への変更

特筆すべき変化はありません。

2019.2.2 から 2019.2.3 への変更

再構築された .NET ビルドランナー

.NET CLI(dotnet)ビルドランナーはリファクタリングされ、.NET に名前が変更されたため、以前は TeamCity に複数のビルドステップとして実装されていたすべての .NET 関連の操作をサポートするようになりました。

既存のすべての .NETCLI(dotnet)ステップは、追加の調整を必要とせずに、新しい .NET 名で通常どおり機能し続けます。

MS ビルドVisual Studio (sln)Visual Studio 2003Visual Studio テストランナーのアクティブサポートの提供を停止します。これらの手順は、既存のビルド構成と TeamCity の新しいバージョンとの互換性のために残されています。影響を受けるすべてのビルドステップを .NET ランナーに切り替えて、次のバージョンの新機能とサポートを利用することをお勧めします。

新しい .NET ステップと移行に関する注意事項について詳しくは、.NET の説明を参照してください。

.NET ランナーへの移行で問題が発生した場合、またはその他の関連する問題が発生した場合は、便利なフィードバックチャネルを介して遠慮なくご連絡ください。

既知の問題

SSL 接続の確立時のハンドシェイクの失敗

一部のユーザーは、TeamCity サーバーが SSL 接続を確立しようとすると、「致命的なアラートを受信しました: handshake_failure 」エラーが発生する場合があります。この問題は、TeamCity 2019.2.3 にバンドルされている JRE の sunec.dll が壊れていることが原因です。

この問題がインストールに影響したかどうかを確認するには、<TeamCity_installation_directory>/jre/bin/sunec.dll ファイルを開きます。このファイルに JSON コードがある場合、サーバーが影響を受けます。この問題を回避するには、関連する問題(英語)に記載されている手順に従ってください。

外部リポジトリの NuGet フィード認証情報が .NET ランナーで機能しない

.NET ビルドランナーは現在、外部リポジトリでの認証に NuGet フィード資格情報を使用することをサポートしていません。

TeamCity 2019.2.3 でこの問題を回避するには、パッチが適用された .NET パッケージサポートプラグイン(英語)をダウンロードして、他の追加プラグインとしてインストールします。バンドルされている .NET パッケージサポートプラグインは、次のリリースで修正により自動的に更新されます。

AWS リージョン us-east-1 は S3 アーティファクトストレージ設定で設定できません

S3 アーティファクトストレージ設定で us-east-1 リージョンが選択されている場合、設定を保存すると、別の使用可能なリージョンに自動的にリセットされます。これは、AWS から us-east-1 に対して返された誤ったバケットの場所が原因です。

TeamCity 2019.2.3 でこの問題を回避するには、パッチが適用された TeamCity S3 ストレージプラグイン(英語)をダウンロードして、他の追加プラグインとしてインストールします。バンドルされている S3 Storage プラグインは、次のリリースで修正により自動的に更新されます。

バンドルされた Java for Windows インストーラーが更新されました

TeamCity サーバーとエージェントの Windows インストーラー、および Docker イメージの Java のバンドルバージョンが Amazon Corretto 8.252.09.1(英語) に更新されます。

2019.2.1 から 2019.2.2 への変更

Git サブモジュールのキャッシュ

エージェントのチェックアウトのパフォーマンスを向上させるために、TeamCity は通常の Git リポジトリをエージェントにキャッシュします。このバージョン以降、Git サブモジュールもキャッシュされます。
カスタムスクリプトまたは設定がサブモジュールのメインの代替ソースに依存していて、Git がエラーで動作する場合は、次の回避策のいずれかを検討してください。

  • ビルドパラメーター teamcity.internal.git.agent.submodules.useMirrorsfalse に設定して、新しいミラーリングメカニズムを無効にします。

  • 正確なソースディレクトリではなく、親 git ディレクトリを指すようにカスタム設定を変更します。

付属ツールのアップデート

  • TeamCity Visual Studio アドイン Web インストーラーは、ReSharper バージョン 2019.3.2 に更新されました。

2019.2 から 2019.2.1 への変更

特筆すべき変化はありません。

2019.1.x から 2019.2 への変更

既知の問題

.NET プロジェクトでの NuGet パッケージの復元に関する潜在的な問題

ビルドに少なくとも 1 つの .NET CLI(dotnet)ステップと MS ビルドまたは Visual Studio (sln) ビルドステップ(またはその両方)が含まれている場合、TeamCity は NuGet パッケージの復元に失敗する可能性があります。

この問題は、これらのビルドランナー間のキャッシュディレクトリへのパスの違いが原因で発生します。
MSBuild および Visual Studio(sln)ランナーは、NuGet グローバルキャッシュへのデフォルトパスを使用しますが、.NET CLI(dotnet)ランナーは、このパスを再定義します(たとえば、Docker コンテナー内で実行する場合)。

推奨される回避策は、パッケージの復元に .NET CLI(dotnet)ランナーの代わりに NuGet インストーラービルドランナーを使用することです。

Windows インストーラーおよび Docker イメージで 64 ビット Bundled Java に切り替える

TeamCity サーバーおよび Agent の Windows インストーラーおよび Docker イメージに含まれる Java のバンドルバージョンは、64 ビット Amazon Corretto(英語) 8 です(以前の TeamCity バージョンは 32 ビット Java にバンドルされ、TeamCity 2019.1 は AdoptOpenJDK にバンドルされました)。

Windows でデフォルトのバンドル Java を使用していた場合は、次の条件が満たされていることを確認してください。

  • TeamCity サーバーとエージェントは、64 ビット Windows OS 上で動作します。32 ビット OS を使用する必要がある場合は、32 ビット Java をインストールして使用して TeamCity を実行する必要があります。

  • TeamCity サーバーが手動でメモリ設定を構成している場合TEAMCITY_SERVER_MEM_OPTS 環境変数が定義されている場合)、-Xmx パラメーターの値を増やす必要があります(前の値の 2 倍に推奨)。値を増やす前に、マシンに十分な物理メモリがあることを確認してください。

  • 統合 MS SQL 認証で TeamCity データベースとして Microsoft SQL Server を使用する場合、64 ビット sqljdbc_auth.dll ネイティブライブラリが予定の場所に存在する必要があります

  • サーバー上でネイティブツールを実行するカスタムロジックがあった場合、新しいプロセスビットネスで動作することを確認します。

実行中のビルドノードの廃止

ビルドノードの実行(英語)は廃止されました。マルチノードのセットアップでは、代わりに「ビルドの実行によって生成されたデータの処理」の責任でセカンダリノード構成できます。詳細については、マルチノード設定ページを参照してください。

git fetch memory の自動管理

TeamCity は、git fetch プロセスによって使用されるメモリの量を自動的に管理できるようになりました。
以前に teamcity.git.fetch.process.max.memory 内部プロパティを使用して各 VCS ルートでフェッチできるメモリ量を設定したことがある場合は、これを無効にして、メモリ消費の検出を TeamCity サーバーに委譲できるようになりました。使用可能なメモリの制限を制御するには、teamcity.git.fetch.process.max.memory.limit プロパティを使用します。

付属ツールのアップデート

  • バンドルされた IntelliJ IDEA は、バージョン 2019.3 に更新されました。

  • TeamCity DSL で使用される Kotlin は、バージョン 1.3.60 にアップグレードされました。

  • TeamCity Linux エージェントイメージの Docker クライアントは、バージョン 19.03.3 にアップグレードされ、予期しない Docker 停止の問題を回避しています(関連する Docker の問題(英語)を参照)。

  • Docker Compose はバージョン 1.24.1 に更新されました。

  • バンドルされた dotCover および ReSharper CLT は、バージョン 2019.2.3 にアップグレードされました。

ClearCase および SourceGear Vault 用のバンドルされていない VCS サポートプラグイン

ClearCase(英語) および SourceGear Vault(英語) の VCS サポートプラグインはバンドルされていません。TeamCity でこれらの VCS タイプのいずれかを使用できるようにするには、ここで説明されているように、必要なプラグインをダウンロードしてインストールします。

2019.1.4 から 2019.1.5 への変更

2019.1.3 から 2019.1.4 への変更

  • バンドルされた Java は OpenJDK 8u222 に更新されました(Docker Windows TeamCity イメージを除く)。

既知の問題

Amazon ECR で使用できないデフォルトの資格情報プロバイダーチェーンオプション

この問題は TeamCity 2019.1.5 で修正されています。

Docker サポートプラグインの最近の変更により、Amazon ECR 接続設定で「デフォルトの資格情報プロバイダーチェーン(英語)」オプションが使用できなくなります。

このオプションが以前に一部の ECR 接続で有効になっていて、この接続に変更を加えた場合、このオプションの状態は自動的に false に設定されます。ビルドがこの接続を使用しようとすると、「アクセスキーを null にすることはできません」というエラーで起動に失敗します。

2019.1.5 にアップグレードせずにこの問題を回避するには、関連する問題(英語)から修正された Docker サポートプラグインをダウンロードし、サーバー管理 | プラグインリストページにアップロードします。

NuGet フィードに不足しているパッケージ

この問題は TeamCity 2019.1.5 で修正されています。

特定のケースでは、ビルドで複数の NuGet パッケージを作成して NuGet フィードに公開することになっており、パッケージのインデックス付けが有効になっていると、一部のパッケージがフィードに公開されない場合があります。この問題は、NuGet パッケージインデクサの最近の変更が原因です。

2019.1.5 にアップグレードせずにこの問題を回避するには、関連する問題(英語)から修正された NuGet サポートプラグインをダウンロードし、サーバー管理 | プラグインリストページにアップロードします。

2019.1.2 から 2019.1.3 への変更

既知の問題

  • バージョン設定を使用する場合、VCS から設定をインポートするとビルド履歴が失われる可能性があります。詳細 (英語)

付属ツールのアップデート

  • バンドルされている ReSharper コマンドラインツール(インスペクションおよび重複ファインダー)は、バージョン 2019.2.1 にアップグレードされています。

2019.1.1 から 2019.1.2 への変更

既知の問題

  • バージョン設定を使用する場合、VCS から設定をインポートするとビルド履歴が失われる可能性があります。詳細 (英語)

  • Windows エージェントで .NETCore("dotnet")の手順を使用する場合、エージェントの C:\Program Files (x86)\dotnet などの場所に .NET Core ランタイム(SDK ではない)がインストールされていると、「。NETSDK が見つかりませんでした」エラーが発生する可能性があります。回避策として、env.DOTNET_HOME パラメーターを .NET CoreSDK の場所に設定します。
    詳細については、関連する問題(英語)を参照してください。

2019.1 から 2019.1.1 への変更

付属ツールのアップデート

  • バンドルされている IntelliJ IDEA が 2019.1.3 に更新されました。

  • バンドルされている ReSharper ツール(インスペクションと重複ファインダー)は 2019.1.0-eap08d バージョンにアップグレードされました。

2018.2.x から 2019.1 への変更

Amazon インスタンスの必須タグ

タグは、TeamCity によって実行されるすべての Amazon インスタンスに必須になり、タグの識別に役立ちます。Amazon EC2 との統合を使用する場合は、Amazon に ec2:CreateTags (英語) リソースレベルのパーミッションを追加してください。

逆依存関係プロパティの動作の変更

2019.1 以降、 reverse.dep パラメーターの動作が変更されました。この変更は、既存のビルドに影響を与える可能性があります。2019.1 より前のバージョンでは、ビルドチェーンがトリガーされると、TeamCity は、チェーンの最上位ビルド、つまり他のすべてのビルドに依存するビルドで指定された reverse.dep パラメーターのみを考慮しました。チェーンの一部の中間ビルドに reverse.dep パラメーターがある場合、それらは無視されました。
この修正(英語)後、これは当てはまり(英語)ません。これで、ビルドチェーンがトリガーされると、ビルドチェーンのすべてのノードで指定されたすべての reverse.dep パラメーターが処理されます。

遅延エージェントツールの読み込み

エージェントツール(エージェントの <agent_installation>/tools ディレクトリにあります)は、エージェントのアップグレードではなく、それぞれのツールを使用する最初のビルドの直前にエージェントに転送されるようになりました。TeamCity がビルドに必要なツールを認識できるように、ビルド構成設定を更新する必要がある場合があります。
エージェントでビルドを開始する前に、TeamCity は teamcity.tool.<tool_ID> 構成パラメーターへの参照をチェックして、ビルドで使用されるツールのセットを収集します。このパラメーターを介して一部のツールが参照されている場合、TeamCity は、ビルドロジックの実行を開始する前に、このツールがエージェントに存在することを確認します。
一部のビルドが <agent installation>/tools ディレクトリの場所を想定してエージェントでツールを使用する場合、そのような参照は TeamCity が提供するパラメーター参照に変更する必要があります。TeamCity 設定で使用される <agent_installation>/tools/<tool_ID> のようなパスは、%teamcity.tool.<tool_ID>% パラメーター参照に変更する必要があります。例: ../tools/maven3.4.5/bin/mvn%teamcity.tool.maven3.4.5%/bin/mvn に置き換える必要があります。

ReSharper ツールの .NET ビルド要件の変更

ReSharper ツールで使用される .NET フレームワークバージョンの要件は変更されました。ビルド構成で 2018.2 以降のバージョン(TeamCity 2019.1 にバンドルされているバージョンを含む)の ReSharper ツール(dotCover および ReSharper インスペクション)を使用する場合、エージェントをビルドするための要件は .NET フレームワーク 4.6.1 以降に変更されます。エージェント上で .NET フレームワークを必ず更新してください。

デフォルトで有効なトークンベースの認証

2019.1 にアップグレードすると、トークンベース認証モジュールがデフォルトで有効になるため、アクセストークンを生成してすぐに使い始めることができます。

新しい CSP ヘッダー値

現在、TeamCity Web UI は、 Content-Security-Policy (英語) HTTP ヘッダーに対してより制限的な値を使用しています。これにより、TeamCity サーバーでホストされていない Web リソースの使用が禁止されるという犠牲を払って、追加のセキュリティが提供されます。
外部リソースに依存している場合(たとえば、ビルドレポートタブのコンテンツで、またはまだ更新されていないプラグインを使用して)、teamcity.web.header.Content-Security-Policy.protectedValue=<full_header_value> 内部プロパティ(および管理領域の Web ページの teamcity.web.header.Content-Security-Policy.adminUI.protectedValue プロパティ)で新しいヘッダー値を指定できます。プラグインは、 ContentSecurityPolicyConfig (英語) オープン API インターフェースを使用して、構成された値に追加できます。

dotCover アーティファクトの変更

dotCover.dcvr 非表示アーティファクトはデフォルトで公開されなくなりました。これで、ビルド一時フォルダーに作成され、ビルドが終了すると削除されます。
dotCover を使用し、このアーティファクトに依存する場合は、アーティファクトパス%system.teamcity.build.tempDir%\..\agentTmp\dotNetCoverageResults\dotCover.dcvr ファイルへのパスを明示的に指定してください。

付属ツールのアップデート

  • 最新の JaCoCo バージョン(0.8.4)が TeamCity に追加されました。

  • バンドルされている .NET ツール(dotCover および ReSharper CLT)は、最新のリリースバージョン 2019.1.1 にアップグレードされました。

  • 新規 TeamCity インストールで推奨される外部データベース用の JDBC ドライバーは、以下のバージョンに更新されました。
    • MySQL - 8.0.16

    • MSSQL - 7.2.2

    • PostgreSQL - 42.2.5

PowerShell のベータ版に関する注意

PowerShell のベータ版を使用している場合は、PowerShell の新しいリリースをインストールする前に、v6.0.0-beta.9 より前のベータ版をすべて削除してください。PowerShell ディテクターの更新により、古いベータ版がインストールされている場合、TeamCity は新しくリリースされたものの代わりにそれを使用します。

プロセス分離で Docker と Windows Server を使用する場合の注意

Docker イメージとプロセス分離を備えた WindowsServer 2019 を使用している場合、ビルドエージェントの起動に失敗する可能性があります(詳細については、既知の問題を参照してください)。この問題を回避するには、「フルコントロール」を付与します。「認証されたユーザー」へのアクセスグループ。

2018.2.3 から 2018.2.4 への変更

不正なエージェントのページに表示されたデータに関連した TeamCity 2018.2.4 の後退があります: エージェント承認、コメントの有効化 / 無効化、および最新の活動時間に関するデータがページから削除されます。このデータはエージェントの詳細ページに表示されます。

パフォーマンスが向上したら、不正なエージェントのページにデータを返します。

2018.2.2 から 2018.2.3 への変更

TeamCity は、1803/1809 プラットフォーム用の Windows Docker イメージを提供します。

既知の問題

完成したビルドがない場合、実行中のビルドはビルド構成ページに表示されません。この問題を回避するには、TeamCity サーバーを停止し、TEAMCITY_DIRECTORY/webapps/ROOT/js/ring/bundle.jsこの問題(英語)に添付されている bundle.js ファイルに置き換えて、サーバーを起動します。

2018.2.1 から 2018.2.2 への変更

  • バンドルされている Tomcat はバージョン 8.5.3 にアップデートされました

  • TeamCity エージェントの Docker イメージは .NET Core 2.2 をサポートします

2018.2 から 2018.2.1 への変更

特筆すべき変更はありません

2018.1.x から 2018.2 への変更

既知の問題

  • MoveCustomDataStorageToDatabaseConverter または MoveRepositoryStateToCustomDataStorageConverter のエラーでアップグレードが失敗した場合は、問題(英語)の回避策を適用してください。

  • 同じリポジトリの Subversion 外部を使用している場合、誤ったリビジョン検出で問題が発生する可能性があります。この問題の回避策は、この号(英語)で説明されています。

  • org.jetbrains.dokka をスタックトレースにした状態で TeamCity の起動時に OutOfMemoryError が表示される場合は、内部プロパティ teamcity.kotlinConfigsDsl.docsGenerationXmx=768m を設定してください。( この号(英語)で説明されているように)

付属ツールのアップデート

  • バンドルされている .NET ツール(dotCover および ReSharper CLT)は、最新のリリースバージョン 2018.1.4 にアップグレードされました。

  • TeamCity 2018.2 は IntelliJ IDEA 2018.3.1 にバンドルされています。IntelliJ IDEA プロジェクトランナーは JPS 2018.3.1 を使用

  • OpenJDK は、Oracle Java の代わりに Windows .exe TeamCity ディストリビューションにバンドルされています。

NuGet フィード

グローバル NuGet フィードを参照するために以前使用されていたパラメーターは削除されました。アップグレード後、それらはすべてルートプロジェクトのデフォルトの NuGet フィードを参照するパラメーターに変換されます。

まだプロジェクトパラメーターで廃止予定の NuGet フィード参照を使用している場合は、次のように更新してください。

グローバルフィード名

プロジェクトフィード名

teamcity.nuget.feed.server

teamcity.nuget.feed.guestAuth._Root.default.v2

teamcity.nuget.feed.auth.server

teamcity.nuget.feed.httpAuth._Root.default.v2

system.teamcity.nuget.feed.auth.serverRootUrlBased.server

teamcity.nuget.feed.httpAuth._Root.default.v2

2018.1.4 から 2018.1.5 への変更

特筆すべき変更はありません

2018.1.3 から 2018.1.4 への変更

既知の問題

  • Builds which are running while the server upgrades to 2018.1.4 can get their build log and status truncated, not duly reporting build failure. The build log gets warning with "__tc_longResponseMarker" text (details(英語) ). It is recommended to wait till there are not running builds when upgrading to this version.

その他

Microsoft Internet Explorer 10 のサポートは TeamCity 2018.1.4 で廃止されます。

2018.1.2 から 2018.1.3 への変更

付属ツールのアップデート

最新の JaCoCo バージョン(0.8.2)が TeamCity に追加されました。

既知の問題

JaCoCo カバレッジを使用していて、TeamCity 2018.1.3 + から TeamCity バージョンの 2018.1 - 2018.1.2 にダウングレードすることを決定した場合、影響を受ける構成を再度機能させるために手動修正が必要な問題が発生する可能性があります。

2018.1.1 から 2018.1.2 への変更

既知の問題

If you are using tcWebHooks(英語) third-party TeamCity plugin, update it to the latest version before upgrading (details(英語) ).

同様の TeamCity 終了コード構築問題を認識するための精度を高めました。これらのビルド問題に関する既存の調査とミュートはリセットされます。

付属ツールのアップデート

バンドルされている Tomcat はバージョン 8.5.32 にアップデートされました。

2018.1 から 2018.1.1 への変更

既知の問題

2018.1 から 2018.1.1 にアップグレードしていて、TW-55703(英語)TW-55833(英語) の問題が原因で NuGet パッケージが見つからない場合は、次の手順を実行してください。

  • ビルドアーティファクトの .teamcity/nuget/packages.json ファイルをクリーンアップします。この PowerShell スクリプトの使用を検討してください。

> cd "%TeamCityDataDir%\system\artifacts\" > Get-ChildItem -Recurse | Where-Object { $_.FullName -match '\.teamcity\\nuget\\packages\.json' } | Remove-Item
  • 管理 | 診断 | キャッシュページで、「buildsMetadata」キャッシュをリセットし、インデックスの再作成が完了するまで待ちます。インデックス作成速度を一時的に上げるには、次のヒント(英語)を参照してください。

Docker イメージ

2018.1.1 TeamCity には、latest でマークされたマルチプラットフォームの Docker イメージと、Docker Hub で公開されたバージョン番号タグ( jetbrains/teamcity-serverjetbrains/teamcity-server:2018.1.1 など)があります。これにより、Linux および Windows の docker コンテナーに同じ Docker イメージ参照を使用できます。詳細については、TW-55061(英語) を参照してください。

2017.2.x から 2018.1 への変更

既知の問題

複数のビルドステップで NuGet パッケージを TeamCity NuGet フィードにパブリッシュすると、最初のビルドステップでパブリッシュされたパッケージのみが表示されます。詳細は TW-55703(英語) を参照してください。アーカイブ内で公開されている NuGet パッケージのダウンロードに関する問題が発生した場合は、TW-55833(英語) を参照してください。

パラメーター参照で使用されるパラメーター名の厳密な規則

ビルド構成パラメーターの名前がより厳密に検証されるようになりました。既存のパラメーターは引き続き機能するはずですが、名前を確認してラテン文字を使用し、特別な記号を使用しないことを強くお勧めします。詳細

ユーザー自己登録

ログインページからのユーザー登録を許可する設定を有効にして組み込み認証を有効にしている場合、この設定はアップグレード時に無効になります。登録が必要な場合は、サーバーが許可されていないユーザーアクセス(インターネットからアクセスできないなど)に開かれていないことを確認し、管理ページの上部または管理、認証の順に表示されるヘルス項目で設定を有効にします。「内蔵」モジュール設定

付属ツールのアップデート

  • IntelliJ IDEA Project Runner は、最小バージョンとして Java 1.8 を必要とする JPS 2017.3.4 を使用します。

  • バンドルされている ReSharper CLT と dotCover はバージョン 2018.1.2 に更新されました

NuGet フィード

  • NuGet フィードの設定は、サーバーレベルからプロジェクトレベルに移動しました。各プロジェクトは独自のフィードを持つことができます。アーティファクトを索引付けする必要がある構成をビルドするために、「NuGet パッケージインデクサー」ビルド機能を追加することができます。

  • 次の NuGet フィード関連のビルドパラメーターは非推奨です。

    • teamcity.nuget.feed.auth.server
    • teamcity.nuget.feed.server
    • system.teamcity.nuget.feed.auth.serverRootUrlBased.server

    ここで、プロジェクト設定NuGet フィードページから URL を明示的に指定する必要があります。

  • URL /app/nuget/v1/FeedService.svc/ によってアクセスされるすべての発行済みパッケージを含む有効なデフォルト NuGet フィードが、ルートプロジェクトフィード /app/nuget/feed/_Root/default/v2/ に移動されます。プロジェクトで新しい URL に切り替えることをお勧めします。

  • .nupkg ファイルは、サーバーではなくエージェント側で索引付けされるようになりました。これにより、NuGet フィード機能と自動パッケージ索引付けが有効になっているプロジェクトまたは NuGet パッケージインデクサービルド機能付きのビルドのビルド時間が少し長くなります。

REST API

REST API はバージョン 2018.1 を使用します。以前のバージョンの API は、/ app / rest / 2017.2、/ app / rest / 2017.1(/ app / rest / 10.0)、app / rest / 9.1、/ app / rest / 9.0、/ app / rest / にあります。8.1、/ app / rest / 7.0、/ app / rest / 6.0 の URL。次のリリースではそれらを削除する予定であるため、以前の API URL の使用を中止することをお勧めします。

エージェント名によるビルドのフィルタリング

エージェント名に括弧記号が含まれている場合は、agentName:<名前> を使用する代わりに、"agentName:(値: <値>)を使用してください。

"value:< テキスト >" を持つロケータ

"value:<テキスト>" ロケーターを使用し(プロパティのマッチングなど)、"matchType" ディメンションの指定を使用しないリクエストでは、デフォルトで "equals" マッチングが使用されます。古い動作を維持するために "matchType:contains" を追加してください。詳細 (英語)

VSS プラグインはバンドルされていません

Visual SourceSafe プラグインは TeamCity にバンドルされなくなりましたが、個別のダウンロード(英語)として入手できます。ビルドにこの VSS を引き続き使用する場合は、サポートにお問い合わせください。

その他

  • Commit Status Publisher は、Gerrit 2.6+ バージョンをサポートします。古い Gerrit バージョンのサポートについては、私たちに回してくださいサポート

  • 9.1 より前のバージョンの TeamCity からアップグレードする場合、TeamCity 2018.1 が起動してエージェントがアップグレードされているのに、サーバーを以前の TeamCity バージョンにロールバックすることにした場合、エージェントは古いサーバーに接続できなくなり、手動で再インストールする必要があります。

  • エージェントからサーバーへの HTTP リクエストがブロックされていないことを確認してください (たとえば... / app / agents / ... URL へのリクエスト)

  • 2018.1 以降、TeamCity は、プロジェクト - サブプロジェクトの完全なプロジェクト名が存在する場所には、"::" の代わりに "/" を使用して完全なプロジェクト名を区切り文字として使用します。

2017.2.3 から 2017.2.4 への変更

インスペクション(.NET)および重複ファインダー(.NET)ビルドステップは、インスペクション(ReSharper)および Duplicates finder(ReSharper)に名前が変更されました。

2017.2.2 から 2017.2.3 への変更

リビジョンを作成する

すべてのビルド構成で、アップグレード前に実行されたビルドはチェーンで再利用されず、新たに実行されます(ブランチが使用されている場合、デフォルトブランチの最後のビルドのみが影響を受けます)。また、これにより、Perforce などの VCS の初回実行ビルドでクリーンなチェックアウトが行われる場合があります。この動作は、VCS ルート編集後の動作に似ています。

セキュリティ

2017.2.x バージョンにアップグレードする場合(2018.1 以降のバージョンにアップグレードする場合は無視してください): サーバーのセキュリティを強化するために "teamcity.artifacts.restrictRequestsWithArtifactReferer=true" 内部プロパティを追加することをお勧めします。

2017.2.1 から 2017.2.2 への変更

既知の問題

(2017.2.3 を修正)Artifactory プラグインを使用していて、ビルドステップ設定を開いたときに「無効な RSA 公開鍵」ブラウザーメッセージが表示される場合は、回避策(英語)を適用してください(英語)

Windows では、TeamCity サーバーをサービスとして起動すると、"logs \ teamcity-winservice.log" ファイルは作成されず、サーバーの起動エラーは表示されません。詳細 (英語)

IDE プラグイン

すべてのユーザー用の IDE プラグインを最新バージョンに更新してから teamcity.uploadPersonalPatch.requireAuthorization=true 内部プロパティを追加してサーバーのセキュリティを強化することを強くお勧めします。

Perforce VCS ルート実行可能パス

TeamCity 2017.2.2 以降、p4 へのパスを指定するフィールドは、エージェント側のチェックアウトのために、エージェント側でのみ機能します。

For the server, the p4 binary should be present in the PATH of the TeamCity server (or can be specified via the teamcity.perforce.customP4Path internal property ). The teamcity.perforce.p4PathOnServerWhitelist internal property can be used to specify a semi-colon-separated list of allowed p4 paths. The paths from this list can be set in VCS Root p4 path parameter for the server side (to restore old behavior).

Mercurial VCS ルートプロパティ

TeamCity 2017.2.2 以降、多数の Mercurial VCS ルートプロパティはセキュリティ上の理由でそれらの動作を変更します。

  • 「HG コマンドパス」は、ホワイトリスト(英語)に含まれている場合にのみ TeamCity サーバーで使用されます

  • VCS のルートにまだリポジトリが作成されていない場合、"Clone repository to" プロパティは非表示になり、デフォルトで無視されます。TeamCity がすべての VCS ルートでプロパティを表示するようにするには、teamcity.hg.showCustomClonePath=true 内部プロパティを追加します。VCS ルートプロパティの値は、teamcity.hg.customClonePathWhitelist 内部プロパティで指定されたホワイトリストに含まれている場合にのみ考慮されます。これは、クローンが許可されるディレクトリのセミコロン区切りリストです。 /path/to/dir/* を使用して、/path/to/dir の子ディレクトリへのクローンを許可します。

  • "Mercurial config" はサーバー上では無視されます。Mercurial プラグインを有効にする必要がある場合は、グローバルにそれを行ってください。TeamCity サーバーマシン上の hgrc

2017.2 から 2017.2.1 への変更

Kotlin DSL の変更

pom.xml のバージョンが更新されます: kotlin.version1.2.0 に更新され、teamcity.dsl.version2017.2.1 に更新されます。jdk8 で利用可能な追加機能(正規表現の名前付きグループなど)へのアクセスを提供するために、kotlin-stdlib への依存関係が kotlin-stdlib-jdk8 への依存関係に置き換えられます。非推奨の kotlin-runtime への依存関係と kotlin-compiler-embeddable への冗長な依存関係は削除されます。

TeamCity は、teamcity.dsl.version および kotlin.version プロパティを定義する Kotlin DSL の親 maven プロジェクトを提供します。このような親プロジェクトでは、各 TeamCity のアップグレード後に pom.xml を更新する必要はありません。

これらの変更を適用する最も簡単な方法は、プロジェクト管理領域で「Kotlin フォーマットで設定をダウンロードする」アクションを実行し、theTeamCity サーバーによって生成された zip から pom.xml を使用することです。

Docker イメージで使用されるバンドル Java

Docker イメージで使用されているバンドル Java は 8u151 に更新されています。

2017.1.x から 2017.2 への変更

既知の問題

(2017.2.1 が修正されました)(チームエクスプローラーがマシンにインストールされていない場合)Java 作業モードの TFS が "TFS サブシステムが破壊されました " というエラーを報告します。詳細は TW-52685(英語) を参照してください。

TeamCity インストールディレクトリにネストされたディレクトリが多数含まれている場合(たとえば、TeamCity データディレクトリがそにある場合)、Windows インストーラを使用したアップグレードにはかなりの時間がかかる場合があります。長い段階は、「Extract:Uninstall.exe ...」進行メッセージの後に発生する可能性があります。この長いステップが発生した場合は、操作の補完を待ってください(インストーラーはネストされたプロセスとして icacls.exe ユーティリティを実行します)。この問題を防ぐために、データディレクトリを TeamCity サーバーの設置場所から移動することをお勧めします。

Perforce ブランチの仕様変更

ブランチ機能を有効にした Perforce ストリームを使用していて、デフォルト以外のブランチフィルターを使用している場合、アクションが必要になるという重大な変更があります。

TeamCity 2017.2 から始まって、Perforce VCS ルートは Perforce ストリームと TeamCity 機能ブランチ仕様のために同じフォーマットを使います。

Perforce の VCS Root ブランチ仕様では、+:stream_name+://stream_depot/stream_name に置き換えられる必要があります。また、UI でのストリーム名の表示を良くするために、+:* のようなデフォルトのブランチ仕様を +://your_stream_depot/* に置き換えることをお勧めします。

この変更は TW-48038(英語) の修正の範囲内で行われました。

サーバープロセスの再起動

サーバープロセスが予期せずに停止または強制終了された場合、プロセスは自動的に再起動します。正常な停止を実行する teamcity-server.bat/sh stop コマンドを使用してサーバーを停止する必要があります。

バンドルされたプラグイン

Docker 統合プラグイン

Docker 統合プラグインは TeamCity 2017.2.x 以降にバンドルされています。以前のバージョンのプラグインを手動でインストールした場合は、削除して(英語)ください。

.NET CLI プラグイン

.NET CLI(.NET Core)プラグインは、TeamCity 2017.2.x 以降にバンドルされています。以前のバージョンのプラグインを手動でインストールした場合は、削除して(英語)ください。

アップグレード中、既存の .NET Core ビルドステップはすべて .NET CLI ステップに変換され、既存の .NET Core プラグインは無効になります。

: DotNetCore および DotNetCore_Path エージェント構成パラメーターは、DotNetCLI および DotNetCLI_Path に変更されます。これらのパラメーターに依存するエージェント要件の更新を検討してください。

REST API

REST API はバージョン 2017.2 を使用します。以前のバージョンの API は、/ app / rest / 2017.1(/ app / rest / 10.0)、app / rest / 9.1、/ app / rest / 9.0、/ app / rest / 8.1、/ app / rest / にあります。7.0、/ app / rest / 6.0 の URL。

buildType エンティティ

複数のテンプレートをサポートするために、"template" の代わりに "templates" サブ要素が追加されました。

エンティティの構築ブール値の「実行中」属性を公開しなくなりました。代わりに、値「実行中」のテキスト「状態」属性が使用されます。

Windows バージョンのサポート

Windows XP と Vista は、TeamCity サーバーとエージェントでサポートされている Windows のバージョンではなくなりました。サーバーとエージェントは、おそらくこれらの古いバージョンで動作するでしょうが、開発中のバージョンをターゲットにしていません。バージョンのサポートが TeamCity の使用にとって重要である場合、またはシステムサポートに問題がある場合は、知らせて

J2EE Servlet 2.5 コンテナーはサポートされなくなりました

J2EE サーブレットコンテナーバージョン 2.5 は TeamCity 2017.2 以降サポートされていません。TeamCity は、サーブレット 2.5 を実装する Tomcat 6.x および Jetty 7.x のサポートを保証するものではありません。.war ディストリビューション(非推奨、.tar.gz ディストリビューションが推奨)の場合、TeamCity は Apache Tomcat 7+、J2EE サーブレット 3.0+、および JSP 2.2+ をサポートします。

その他

  • バンドルされている Tomcat 8.5。カーリー括弧記号({})を含む URL 内の特殊文字の使用が制限されています。詳細 (英語)

  • TeamCity と Intellij ベースの IDE との統合では、StarTeam および Visual Source Safe のバージョン管理はサポートされなくなりました。

2017.1.4 から 2017.1.5 への変更

バンドルされた JetBrains dotCover はバージョン 2017.2 に更新されました

SSH エージェントのビルド機能は、指定された SSH キー(TW-42707(英語) の範囲内)で SSH エージェントを起動できなかった場合、ビルドの問題を報告し始めました。前のエラーはログに記録されるだけで、ビルドの問題としては報告されませんでした。その結果、無効な SSH エージェント設定を使用したビルドはアップグレード後に失敗し始めます。

2017.1.3 から 2017.1.4 への変更

既知の問題

TFS パーソナルサポートは TFVC VCS ルートのためのすべてのビルド設定をリストします。詳細は TW-51497(英語) を参照してください。

2017.1.2 から 2017.1.3 への変更

TW-50148(英語) が修正され、DSL API ドキュメントが改善されました。ローカル開発でこれらの変更が必要な場合は、maven 依存バージョンを 2017.1.3 に更新してください。

TeamCity サーバーは git 操作のパフォーマンスを向上させるために 'git gc' を自動的に実行します。これには、git クライアントがサーバーにインストールされていて、PATH 環境変数を介してサーバーになることが必要です。ネイティブの git クライアントが見つからない場合は、対応するヘルスレポートが表示されます。TeamCity が git クライアントを見つけるには、クライアントをサーバーマシンにインストールして $PATH に追加する必要があります(後でサーバーの再起動が必要になります)。PATH を変更する代わりに、teamcity.server.git.executable.path 内部プロパティを介して git クライアントへのパスを指定することができます。

2017.1.1 から 2017.1.2 への変更

特筆すべき変化はありません。

2017.1 から 2017.1.1 への変更

バンドルされている IntelliJ IDEA は 2017.1.2 に更新されました

10.0.x から 2017.1 への変更

既知の問題

クラウドプロファイルを編集すると、プロファイルエージェント上のすべてのビルドがキャンセルされます。詳細は TW-49616(英語) を参照してください。

TeamCity のバージョン管理の変更

2017 年以降、TeamCity は、<year>。<number of the feature release within the year>。<bugfixupdate number> のパターンに従ってバージョンを年ごとに識別する一般的な JetBrains バージョン管理スキームを採用しています。現在のバージョンは、以前は TeamCity 10.1 と呼ばれていた TeamCity 2017.1 です。

Kotlin DSL の設定を更新する

このバージョンでは TeamCity 設定フォーマットが変更されており、設定が Kotlin DSL に保存されている場合、使用する前に Kotlin DSL スクリプトを更新する必要があるかもしれません。サーバーのアップグレード後に、関連するサーバー正常性レポートを確認してください。

CSRF の保護: GET リクエストと適切なプロキシ設定の変更

TeamCity は、Web UI のセキュリティを向上させるために CSRF の保護を実装しました。これにより、インストールに影響を与える可能性のある動作にいくつかの変更が加えられます。特に:

  • TeamCity の前にリバースプロキシを使用する場合、プロキシは元の「Host」リクエストヘッダーを変更しないでください(これには通常、Host ヘッダーを元のリクエスト値に設定するようにプロキシを構成する必要があります)。また、元のリクエストに存在する「Origin」および「Referer」ヘッダーを変更しないでください。これは長い間推奨されるセットアップでしたが、今では TeamCity Web UI が機能するために重要になります。

  • HTTP GET リクエストから TeamCity を実行するバンドルされていないクライアントを使用する場合、一部の GET 要求(http://server/action.html?add2Queue=XXX) のようにサーバーの状態を変更するもの)が 2017.1 で機能しなくなる場合は、GET ではなく POST を使用するように変更してください。

  • TCSESSIONID クッキーにリクエストを供給することによって認証を再利用する非ブラウザークライアントは、リクエストが送信されているホストと同じ値で "Origin" HTTP ヘッダーを供給するように更新される必要があります。チェックが失敗した場合は、失敗したチェックの詳細を含む HTTP 403 レスポンスを取得します。詳細は teamcity-auth.log にも記録されます。

旧知的財産権ランナー

古い(TeamCity 6.0)IPR ランナーは TeamCity から削除されました。TeamCity 6.0 から非推奨となり、オプションとして提供されなくなりましたが、現在は完全になくなりました(対応するビルド構成はもう実行されません)。

Log4j の設定

サーバーの conf\teamcity-server-log4j.xml ファイルを、このリリースで変更されたデフォルトのロギング設定を表す conf\teamcity-server-log4j.xml.dist ファイルの内容で上書きすることをお勧めします。カスタムのロギング設定が必要な場合は、conf\teamcity-server-log4j.xml を変更する代わりにロギングプリセットを使用することを検討してください。

兄弟の .dist ファイルからの同じ上書きが TeamCity エージェントに推奨されます。 conf\teamcity-*-log4j.xml.dist ファイルは、アップグレードされた TeamCity バージョンの最初の起動後に作成されます。

メタデータストレージを構築する (NuGet フィード)

ビルドメタデータストレージは再作成され、ビルドはアップグレード後すぐに再インデックスされます。その結果、アップグレード直後に、TeamCity の内部 NuGet フィードにすべてのパッケージが含まれることはありません。ビルドの再インデックス作成中に、teamcity-server.log に次のメッセージが表示されることがあります。

INFO - .index.BuildIndexer (metadata) - Enqueued next 100 builds for indexing, builds left: 2000, last build id: 3813 INFO - .index.BuildIndexer (metadata) - Enqueued next 100 builds for indexing, builds left: 1900, last build id: 3713

「残りビルド数: 」は、残りのビルド処理数を示します。TeamCity は最新のビルドから再インデックスを開始するため、TeamCity NuGet フィードには比較的短時間で新しいビルドがすべて表示されるはずです。

メタデータのインデックス作成速度を上げるには、次のヒントを参考にしてください

REST API

REST API には小さな変更があるだけなので、同じ API が app/rest/10.0/app/rest/2017.1 の URL で公開されています。変更を反映するために、API バージョンは 2017.1 に更新されます。ビルドのノード "triggerBy" は、2017.1 のアップグレード後に開始されたビルドに対して、より適切な "type" 属性の値を持ちます。特に、"buildType" 値は使用されなくなり、"finishBuild"、"snapshot" などの値が代わりに使用されます。

Visual Studio アドインが TeamCity UI からのインストールに失敗する

回避策として ReSharperWeb インストーラを使用することができます。詳細は TW-51680(英語) を参照してください。

10.0.4 から 10.0.5 への変更

エージェント側のチェックアウトで TFS を使用している場合は、TW-48555(英語) の修正により TeamCity が TFS ワークスペースを再作成する必要があることに注意してください。アップグレード後にエージェントのクリーンチェックアウトが発生する可能性があります。

10.0.3 から 10.0.4 への変更

%dep.ID.NAME% パラメーター参照の優先順位

%dep.ID.NAME% パラメーター参照が使用されていて、ID が "ID" の同じビルド構成への依存パスがいくつかあり、異なるビルドに(直接または間接)アーティファクト依存関係を介してアクセスできる場合、参照解決の結果はいずれのビルドも使用できます。保証された優先順位はありません。

10.0.4 dep. パラメーター解決は次のように機能します。

  1. スナップショットの依存関係がある場合は、同じチェーンからのビルドが優先されます。

  2. スナップショット依存関係がなく、複数のビルドがアーティファクト依存関係を介してアクセス可能な場合は、buildId が大きい方のビルドが優先されます。単一のビルド構成から複数のアーティファクト依存関係がある場合は、最初のものだけが考慮されます。

更新

AWS SDK は、新しいインスタンスタイプ(r4.4xlarge、f1.16xlarge、t2.2xlarge、t4.xlarge、r4.xlarge、r4.large、r4.16xlarge、r4.8xlarge、f1)をサポートするように 1.11.66 に更新されました。.2 倍)

10.0.2 から 10.0.3 への変更

Amazon EBS - 最適化インスタンス

TeamCity 10.0 以降デフォルトで有効になっている EBS 最適化(英語)の動作は、EC2 コンソールが提供するものと同様に変更されます。

  1. EBS 最適化は、c4.*m4.*d2.* (構成不可)ではデフォルトでオンになっています。

  2. 他のインスタンスタイプでは、EBS 最適化はデフォルトで無効になっています。

  3. Amazon クラウドプロファイルのイメージを設定するときに適切なチェックボックスをオンにすることで、それをサポートするインスタンス( c3.xlarge など)に対して EBS 最適化を有効にできます。

付属ツールのアップデート

バンドルされている dotCover はバージョン 2016.2.2 にアップデートされました

10.0.1 から 10.0.2 への変更

  • 10.0.1 に関してメンションされている既知の問題は修正されています。

  • バンドルされた JetBrains dotCover は、バージョン 2016.2 に更新されました。

  • Jabber 統合は、SSL 接続チェックに関してより制限的になり(英語)ました。通知の送信に jabber.org を使用していて、SSL 証明書に関する問題が発生した場合は、レガシー SSL を使用するオプションを有効にするか、(より適切に)TeamCity を実行する JVM バージョンを少なくとも 1.8.0_101 に変更する必要があります。

  • 依存関係としていくつかの異なるビルドが使用されている場合、%dep.ID.NAME% パラメーター解決の優先順位が意図せずに変更されました。詳細は TW-47518(英語) を参照してください。

10.0 から 10.0.1 への変更

10.0 に関してメンションされているすべての既知の問題は修正されています。

既知の問題

(10.0.2 で修正されます)<TeamCity データディレクトリ > /plugins/.tools にエージェントツールがディレクトリとしてインストールされている場合、TeamCity サーバーの一時フォルダーがいっぱいになることがあります。詳細と回避策 (英語)

9.1.x から 10.0 への変更

既知の問題

(これらの既知の問題は 10.0.1 で修正されています)

TFS の変更を収集できませんでした - バージョン が現在のバージョン よりも大きい

If you use TFS version control and get "Error collecting changes for VCS repository ... Failed to collect TFS changes - From version x is greater then current version y" error, either commit a new change so that it appears in the affected build configuration, ot install an updated plugin(英語) (related issue(英語) ).

プロジェクト管理者は、親プロジェクトから継承したパラメーターを再定義できない可能性があります。

詳細および考えられる回避策については、要求 TW-46372(英語) を参照してください。

8.1 より前の TeamCity バージョンからのアップグレードは、「db ロックが保持されていないときは排他ロックを取得できません」というエラーで失敗

詳細および考えられる回避策については、要求 TW-46385(英語) を参照してください。

svn + ssh:// プロトコルを使用した Subversion VCS ルートは、「ホストキー(xxx)を確認できません」と報告することがあります。

詳細および修正を伴うプラグインについては、TW-46385(英語) 要求を参照してください。

.NET 4.x ランタイムを報告するエージェントプロパティの変更

バージョン 10 より前の TeamCity エージェントでは、4.x バージョンの .NET Framework のいずれかがエージェントにインストールされているときは常に DotNetFramework4.0_ * プロパティをレポートしていました。TeamCity 10 以降、DotNetFramework4.0_ * プロパティは 4.0 ランタイム(アップデートなし)がインストールされている場合にのみ報告されます。4.5.*, 4.6.* アップデートの場合、対応する DotNetFramework4.N_ * プロパティがレポートされます。この動作変更により、より正確な要件定義が可能になります。

アップグレード後に満たされていない要件: Exists => DotNetFramework4.0_x86(/ x64)が存在しますメッセージと互換性のないエージェントを受け取った場合は、ビルド構成の明示的な要件を確認してください。あなたのビルドがどの .NET 4.x ランタイムとも互換性がある場合(それが最も一般的なケースです)、存在 => DotNetFramework4.* _ x86(/ x64)要件を使用してください。.NET 4.5+ エージェントで実行したい場合は、存在 => DotNetFramework4。(5|6).* 要件を使用してください。

一部のサードパーティのプラグインが影響を受けることがわかっています。アップグレード時には、xUnit プラグインをバージョン 1.1.2+(英語) にアップグレードしてください。

無視されたテストテーブルの最適化

アップグレード中、TeamCity は ignored_tests テーブルのデータを最適化します(TeamCity の組み込みバックアップ / 復元プロセスをスピードアップするためにこれを行います)。ごくまれに、このテーブルに何百万もの行が含まれていると、テーブルの最適化プロセスにかなりの時間がかかることがあります。他のデータの中でも、表にはビルド内の特定のテストが無視されたとマークされた理由が含まれています。古いビルドに関するこの情報があまり重要でない場合は、追加の JVM オプションを使用して TeamCity サーバーを起動できます。-Dteamcity.truncateIgnoreReasonConverter.copyReasons=false

この場合、TeamCity は無視する理由を新しい最適化されたテーブルにコピーすることはありません。アップグレードプロセスのこの特定のステップは、はるかに高速に実行されます。

Java 8

TeamCity 10 以降、TeamCity サーバー Java 8 が必要です JRE / JDK(Windows .exe ディストリビューションに含まれています)。

TeamCity エージェントは現在 Java 1.6 + を必要としますが、次の TeamCity バージョンから、エージェント上の Java の最小要件は Java 8(エージェントの Windows .exe ディストリビューションに含まれます)になります。エージェント Java のアップグレードを検討することをお勧めします。

Java メモリオプションの変更

以前に構成されている場合は、TEAMCITY_SERVER_MEM_OPTS 環境変数から「-XX:MaxPermSize=..." JVM オプション」を削除することをお勧めします(これは、Java 8 が永続生成(PermGen)を使用しなくなったためです(英語))。

エージェントの要件とアーティファクトの依存関係の無効化

エージェントの要件とアーティファクトの依存関係をすぐに無効にすることができます。TeamCity 10 より前のバージョンの API を使用する TeamCity プラグインおよび REST API ベースのコードは、これらの設定の無効化ステータスを無視する可能性があります。

TFS

TeamCity には、クロスプラットフォームの TFS 統合機能が付属しています。TFS を使用するために、TeamCity サーバーを Windows マシンにインストールする必要はもうありません。

Visual Studio オンライン作業項目プラグイン

Visual Studio オンライン作業項目プラグインは TeamCity 10.0 以降廃止されましたであり、安全に削除できます。TeamCity 10.0 には、TFS 2010+ および Visual Studio チームサービスをサポートする Team Foundation 作業項目(英語)との統合が組み込まれています。アップグレード後、TeamCity は、このプラグインの既存の課題追跡システム接続を検出し、TFS 作業項目に変換します。

新しく作成されたビルド構成のデフォルトチェックアウトモード

新しいビルド設定を作成する際の VCS チェックアウトモードのデフォルト設定が変更されました。現在 TeamCity はビルドの前にエージェント上のソースをチェックアウトします。エージェント側のチェックアウトが不可能な場合、TeamCity はサーバー側のチェックアウトを使用します。明示的なサーバー側またはエージェント側のチェックアウトはまだ行われています。新しいデフォルトは、新しく作成されたビルド構成にのみ適用されます。既存のものはすべて以前の設定どおりに動作します。

プロジェクトベースのエージェント管理権限

新しい TeamCity インストールには、さまざまなエージェント管理権限割り当てがあります。プロジェクト管理者ロールには(グローバル)エージェントマネージャーロールは含まれません。代わりに、プロジェクト管理者ロールにはエージェントプロジェクト権限があり、ユーザーがプロジェクト管理者ロールを持っているプロジェクトのみでエージェントプールからエージェントを管理できます。

ユーザー権限を変更しないために、既存のインストールはこの変更による影響を受けません。ただし、プロジェクト管理者のロールを確認し、「エージェントマネージャー」のロールを除外して次の権限を追加することを検討することをお勧めします。

  • プロジェクトに関連付けられているエージェントを有効 / 無効にする

  • プロジェクト用クラウドエージェントの起動 / 停止

  • プロジェクトのエージェント実行構成ポリシーを変更する

  • プロジェクトエージェントマシンの管理 (たとえば、再起動、エージェントログの表示)

  • プロジェクトエージェントを削除

  • プロジェクト担当者の承認

UI の変更

サーバー管理 UI

新しい管理 | ツールページでは、適切なプラグインによって使用されるツールをセットアップすることができます。ツールはすべてのビルドエージェントに自動的に配布され、関連するランナーで使用できます。

新規プロジェクト作成 / ビルド設定ボタンの作成

新しいサブプロジェクトを作成するおよびビルド構成を作成するボタンにドロップダウンがあり、プロジェクトを最初から(手動で)作成するか、URL から作成するか、一般的なバージョン管理システム GitHub.com および Bitbucket を使用するかを選択できます。

NuGet 関連の UI

NuGet 設定ページは削除されました。NuGet.exe は新しいツールページを使用してインストールできます。TeamCity を NuGet サーバーとして設定するには、管理 | NuGet フィードページに進みます。

テスト関連の UI

問題のあるテストタブは使用できなくなり、過去 120 時間以内に失敗したテストをすべて表示リンクは現在の問題タブから削除されます。

TeamCity は現在、特定のプロジェクトの専用タブに表示されているフレークテストを検出します。

Visual Studio アドイン

TeamCity Visual Studio アドインのレガシーバージョンはサポートされなくなりました。Visual Studio 2005 および 2008 はサポートされていません。

TeamCity Visual Studio アドインは ReSharper Ultimate の一部として提供されます。インストール後、TeamCity アドインは、VisualStudio の RESHARPER メニューから利用できるようになります。

インストーラーは、バンドル前の製品バージョン(9.0 より前の TeamCity および ReSharper バージョン、3.0 より前の dotCover、6.0 より前の dotTrace)を削除することに注意してください。ReSharperUltimate は Visual Studio バージョン 2005 および 2008 をサポートしていません。

IntelliJ IDEA の互換性

IntelliJ IDEA 12.1 以前、および 2013 年より前にリリースされた他の IntelliJ ベースの製品は、IntelliJ プラットフォームプラグインではサポートされなくなりました。

スナップショットの依存関係が再構築を構築

サーバーのアップグレード後、スナップショットの依存関係で適切なビルドがある場合は新しいビルドを実行しないオプションがオンに設定されている場合でも、スナップショットの依存関係として使用されるビルドが 1 回再ビルドされる場合があります。これは、問題(英語)を修正するために行われます。

Perforce

クリーンベースのチェックアウトは、ストリームベースおよびクライアントベースの Perforce VCS ルートを使用したビルドで実施されます。

Subversion

Starting from TeamCity 10, TeamCity does not accept by default connections to SVN servers accessed by https:// protocol with non-trusted server SSL certificate. To enable access with such certificates, you should either import the certificate to server JVM keychain, or enable VCS Root option " 信頼できない SSL 証明書を受け入れる " (Enable non-trusted SSL certificate in 10.0) (issue(英語) ).

付属ツールのアップデート

Ant ランナー: バンドルされている Ant ディストリビューションは 1.9.6 から 1.9.7 にアップグレードされました

.NET dotCover の適用範囲: バンドルされている dotCover は 2016.1 に更新されています

ReSharper コマンドラインツール: バンドルされている R#CLT が 2016.1 に更新されます

Java インスペクションと複製: バンドルされている IntelliJ IDEA は 2016.2 に更新されています

GitHub issue tracker

TeamCity 10.0 より前に TeamCity-GitHub サードパーティのプラグイン(英語)を使用していた場合は、安全に削除できます。内蔵の TeamCity 統合により、GitHub issue tracker への既存の接続が自動的に検出され、設定が自動的に選択されます。

NuGet サポート

設定パラメーター teamcity.tool.NuGet.CommandLine.%NUGET_VERSION%.nupkg はもう報告されていません。代わりに teamcity.tool.NuGet.CommandLine.%NUGET_VERSION% パラメーターを参照してください。

例: %teamcity.tool.NuGet.CommandLine.DEFAULT.nupkg% パラメーターリファレンスを使用する代わりに、%teamcity.tool.NuGet.CommandLine.DEFAULT% を使用する必要があります。

統計を構築する

いくつかの統計値(メトリック)が改善され、名前が変更されました。

  • BuildCheckoutTime から buildStageDuration:sourcesUpdate

  • BuildArtifactsPublishingTime から buildStageDuration:artifactsPublishing

  • ArtifactsResolvingTime から buildStageDuration:dependenciesResolving

チャート定義で古いキーがまだサポートされています。

REST API

REST API はバージョン 10.0 を使用します。以前のバージョンの API は、/app/rest/9.1/app/rest/9.0/app/rest/8.1/app/rest/7.0/app/rest/6.0 の URL で引き続き利用できます。

以前は 404 個の応答があったロケーターが単一のアイテムをアドレス指定しているアイテムのセットを要求すると、より一貫したアプローチとして空のセットが返されるようになります。例: .../app/rest/builds?locator=id:<non-existent build id> REST デバッグログには、ケースに関する詳細を含む診断メッセージが含まれる場合があります。

アイテムの集合すべてまたは不完全な結果が返されるわけではありません(0 個以上のアイテムを含む)を要求し、アイテムの次の「ページ」を取得するためのリンクを nextHref サブエレメントに提供します。 nextHref サブエレメントが指定されていない場合、検索結果は完全です。

一連のアイテムに対するリクエスト(例: ... /app/rest/vcs-roots および... / app/rest/vcs-root-instances)は、ロケーターなしで照会されると、デフォルトでページングされた結果を使用します(それらはすべてのアイテムをリストするために使用されます)。ページサイズを設定するには、"count:NNN" ロケーターディメンション " を追加します。

ビルドを探す.../app/rest/builds/... URL)
ビルドスキャンを実行して、指定されたロケーターに一致するものを見つける場合、デフォルトでは、パフォーマンス上の理由から、TeamCity は、最新の 5000 ビルドのみをスキャンすることによって制限された部分的な結果を返します。履歴の大部分を処理するには、返された nextHref 属性を確認するか、lookupLimit ロケーターディメンションをより大きな値に設定します。
以前は、デフォルト以外のブランチからのビルドを特別に要求し、キャンセルするまで、個人用で開始に失敗したビルドは返されませんでした。現在、これらのフィルターで除外されたビルドは、実行中およびキューに入れられたビルドクエリの場合、およびエージェントまたはユーザーによるフィルターの場合にデフォルトで返されます。 defaultFIlter:true/false ロケーターディメンションを使用して、デフォルトのフィルタリングを明示的に管理します。
また、number:NNN ロケーターは同じデフォルトロジックに準拠するようになりました。デフォルトのブランチからの「通常の」完成したビルドのみが番号で検索され、見つかった場合は複数のビルドを返すことができます。

VCS の根を見つける.../app/rest/vcsRoots/... URL )(マイナー)
project および buildType が指定された VCS ルートロケーターは、buildType を見つけるためのコンテキストとして project を使用しました。これはもはや当てはまりません。ビルド構成を見つけるには、buildType ロケーターが完全なものである必要があります。

構成のアーティファクト依存関係を構築する.../app/rest/buildTypes/... URL によって返されるエンティティ)
buildType 要素の artifact-dependencies サブ要素は、以前の順序に依存していた数値 ID ではなく、テキストで生成された ID を使用するようになりました。これは、アーティファクトの依存関係の変更要求にも影響します。
buildType 要素の agent-requirements サブ要素は、パラメーター名の代わりに生成された ID を id として使用するようになりました。これは、エージェント要件の変更要求にも影響します。

エージェント要件の編集.../app/rest/buildTypes/.../artifact-requirements/... URL)
以前は、同じパラメーターに新しいエージェント要件を追加すると、既存のエージェント要件が新しいエージェント要件によって上書きされていました。新しいものが追加されます。以前は、新しいエージェント要件を追加する際に、パラメーター名は agent-requirement ノードの id 属性から派生していました。TeamCity 10 以降、パラメーター名は「property-name」プロパティから派生しています。

テストと問題の発生.../app/rest/testOccurrences.../app/rest/problemOccurrences URL)
一部のクエリでは、以前のバージョンと比較して、返される結果の並べ替えが変更されています。例: 「../app/rest/testOccurrences?locator=build:(xxx)」リクエストは、ビルドで実行された順序でテストを返すようになりました。
以前は、テストの発生は新しいステータスで並べ替えられ、次に名前で並べ替えられていました。問題の発生は、問題 ID でソートされます。
また、テスト / 問題関連ロケーターの build ディメンションが複数のビルドをサポートするようになったため、「build」ディメンションを介して複数のビルドに一致したリクエストの場合、すべてのビルドが処理されます。以前は、最初に一致するビルドのみが処理されていました。

エンティティ
property エンティティには、テンプレート / プロジェクトから継承されるのではなく、ビルド構成でパラメーターが再定義されるかどうかを示す「独自の」ブール属性がありました。これで、属性の名前が「 inherited」に変更され、その値が反転されます。
vcs-root および vcs-root-instance は、status および lastChecked 属性を持っていました。現在、VCS ルートインスタンスには status 要素( status 属性と timestamp 属性を持つ current ノード)があり、VCS ルートインスタンスが複数ある場合に未定義の結果が生成されるため、VCS ルートにはデータがありません。
test エンティティ id は Long ではなく Sring になりました (JavaScript で JavaLong 値を表現できないため)

ビルドタイプとテンプレート
サポートされているすべての設定を含むために使用される settings ノード。これで、ビルド構成またはテンプレートで定義されたものだけが表示されます。 .../app/rest/buldTypes/XXX/settings/* リクエストについても同様です。デフォルトから変更された値のみが存在します。

適合剤
互換性のあるエージェントを照会すると、ビルドを実際に実行できるエージェントのみが返されるようになりました。デフォルトでは、権限のない、切断され、無効になっているエージェントは表示されません。この動作は、多くの不一致があった以前のバージョンの動作とは異なります。影響を受けるリクエストとエンティティ: .../app/rest/agents?locator=compatible:(...); ../app/rest/agents/.../compatibleBuildTypes および incompatibleBuildTypes; ネストされたノード Agent.compatibleBuildTypesQueuedBuild.compatibleAgentsBuildType.compatibleAgents

9.1.6 から 9.1.7 への変更

特筆すべき変化はありません。

9.1.5 から 9.1.6 への変更

既知の問題

WindowsXP および Vista で実行されるバンドルされた dotCover には既知の問題(英語)があります。提供されている修正プログラム(英語)または回避策(英語)を使用できます。この問題は、次の dotCover リリースで修正される予定です。

ローカルエージェントの内部 TeamCity NuCet サーバーの認証済みフィード URL に対して NuGet クレデンシャル(英語)が機能しないという既知の問題(英語)があります。回避策として、%teamcity.nuget.feed.auth.server% を使用する代わりに、ビルドステップとビルド機能で外部サーバーの URL を指定してください。

NuGet

2.8.6 より前の NuGet バージョンにはビルドエージェントにインストールされた .NET フレームワーク 4.0+、NuGet 2.8.6 以降には .NET 4.5 が必要です。

NUnit

9.1.6 以降、TeamCity は NUnit 3 ベータ版(NUnit 3.0.0 より前にリリースされた)をサポートしません。

NUnit ランナーのアセンブリごとにプロセスを実行するオプションは、NUnit3 の設定から削除されました。対応するフィールドで必要なコマンドラインオプション(英語)を使用して、目的の動作を構成します。

付属ツールのアップデート

バンドルされた IntelliJ IDEA はバージョン # 143.1945 にアップデートされました(いくつかの追加の修正を加えた 15.0.3 とほぼ同等です)。

Maven 3.2.x のバンドルバージョンが 3.2.5 に更新されました。

パフォーマンスモニター

アクセス許可に関する注意: Windows サービス(英語)として実行されるビルドエージェントのパフォーマンス監視するには、エージェントを開始するユーザーが Performance MonitorUsers グループのメンバーであることを確認してください。

9.1.4 から 9.1.5 への変更

既知の問題

WindowsXP および Vista で実行されるバンドルされた dotCover には既知の問題(英語)があります。提供されている修正プログラム(英語)または回避策(英語)を使用できます。この問題は、次の dotCover リリースで修正される予定です。

製品のアイコン

JetBrains 製品アイコンは、新しい JetBrains ブランド(英語)に従って更新されます。

Git

TeamCity 9.1.5 以降、git sparse-checkout はデフォルトで無効(英語)になっています。TeamCity プロジェクトで有効にするには、このプロジェクトに teamcity.git.useSparseCheckout=true パラメーター(英語)を追加します。

Gradle: 9.1.2 と比較した画期的な変更

Gradle プロセスの JVM のシステムプロパティとしてビルド用に定義された TeamCity 9.1.2 で導入された Gradle ランナー system.* プロパティは、9.1.5 以降で機能しません。TeamCity システムプロパティは Gradle スクリプトで Gradle プロパティとしてアクセスでき( gradle.properties ファイルで定義されているものと同様に)、次のように参照されます。

a)Groovy 識別子として許可される名前(プロパティ名にはドットが含まれません): customUserProperty
b)Groovy 識別子として許可されていない名前(プロパティ名にはドットが含まれます。例: build.vcs.number.1 ): project.ext["build.vcs.number.1"]

付属ツールのアップデート

バンドルされた JetBrains IntelliJ IDEA(IDEA インスペクションおよび複製)がバージョン 15.0.2 に更新されました

.NET ツールの更新

JetBrains ReSharper コマンドラインツール(.NET インスペクションおよび複製)が ReSharper 10.0.2 リリースに一致するように更新されました TeamCity Visual Studio アドイン Web インストーラーが ReSharper 10.0.2 リリースに更新されましたバンドル JetBrains dotCover がバージョン 10.0.2 に更新されました

9.1.3 から 9.1.4 への変更

既知の問題

特定のロール / 権限の構成では、ロールの読み込みエラーが発生し、通常のユーザーがプロジェクトを表示できなくなる可能性があります。このような場合、サーバー管理者としてログインしているサーバー管理ページには、「ロール間の循環参照が検出されます」の重大サーバーエラーが表示されます。問題の回避策(英語)を確認してください(英語)

teamcity.git.use.native.ssh=true パラメーターがビルド構成またはエージェント構成で指定されていると、Git エージェント側のチェックアウトが誤動作する可能性があります(TW-43202(英語) で詳細)。これを修正するには、Git プラグインの #snapshot-34(英語) ビルドをインストールしてください。

GZ クライアントのバージョン 1.7.0-1.7.4 では、Git エージェント側のチェックアウトが正しく機能しません。チェックアウトディレクトリにはファイルのみが含まれ、すべてのディレクトリがありません(詳細は TW-43330(英語) にあります)。この問題を回避するには、Root TeamCity プロジェクトに teamcity.git.useSparseCheckout=false パラメーターを追加します。

TeamCity Windows バイナリシグネチャー

9.1.4 以降、TeamCity Windows バイナリは、Microsoft SHA-2 ポリシー(英語)に従って SHA-2 コード署名証明書で署名されています。つまり、Windows XP SP3 より前のシステムでは、実行可能ファイルはコード署名検証に合格しません。新しい Windows システムには、マイクロソフトからの対応するセキュリティ更新プログラムが必要です。

付属ツールのアップデート

バンドルされている Oracle JRE(Server と Agent.exe の両方のインストーラで)はバージョン 1.8.0_66 にアップデートされました (32 ビット)

.NET ツールの更新

JetBrains ReSharper コマンドラインツール(.NET インスペクションおよび複製)は、ReSharper 10.0 リリースに合わせて更新されました

TeamCity Visual Studio アドイン Web インストーラーが ReSharper 10.0 リリースに更新されました

バンドルされた JetBrains dotCover がバージョン 10.0 に更新されました

9.1.2 から 9.1.3 への変更

既知の問題

バンドルされた dotCover 3.2 には既知の問題(英語)があり、次の例外を除いてビルドの失敗を引き起こす可能性があります: 「System.Security.VerificationException:System.Security.VerificationException: 操作によってランタイムが不安定になる可能性があります」。この問題は、TeamCity 9.1.4 リリースにバンドルされている dotCover 10.0 で修正されています。

バンドルされている JVM(Server Windows インストーラーおよび Agent Windows インストーラー)が更新され、その結果、発信 HTTPS 接続に対して SSL RC4 チッパースイートが無効になります。たとえば、これにより、"SSLHandshakeException: 致命的なアラートを受信しました: handshake_failure" エラーが発生し、CloudForge SVN サーバーへの接続が機能しなくなります。(詳細)

9.1.1 から 9.1.2 への変更

既知の問題

スクリプトの先頭にデフォルト以外のハッシュバングが指定されていると、コマンドラインランナーがカスタムスクリプトの実行に失敗することがあります。TW-42498(英語)

Amazon EC2 クラウド統合を使用する場合、ビルドエージェントバージョン 9.1.2-9.1.5 を含む AMI イメージは、EC2-i-abcdefgh および EC2-i-abcdefgh-1 という名前で 2 ライセンス表示され、2 回表示されます。この問題を修正するには、エージェント 9.1.6+ で AMI イメージを使用してください。AMI が同じ場合、サーバーを 9.1.6 に更新するだけでは役に立ちません。(詳細)

ビルドステータスアイコン

ビルドステータスアイコンがより「標準的な」外観に更新され、現在はもう少し大きくなっています。

付属ツールのアップデート

JetBrains ReSharper コマンドラインツール(.NET インスペクションおよび複製)は、ReSharper 9.2 リリースに合わせて更新されました

TeamCity Visual Studio アドイン Web インストーラーが ReSharper 9.2 リリースに更新されました

バンドルされた JetBrains dotCover がバージョン 3.2 に更新されました

バンドルされた Oracle JRE(Server と Agent の両方の .exe インストーラー)をバージョン 1.8.0_60 にアップデート (32 ビット)

9.1 から 9.1.1 への変更

バンドルされている Jacoco カバレッジライブラリがバージョン 0.7.5 に更新されました

Perforce サーバーでパスワード認証が無効になっている場合、チケット認証が無効になっている Perforce VCS ルートは、「p4login」操作を実行しなくなります。
つまり、パスワード認証が無効になっている場合は、VCS ルートでティックベースの認証を使用するオプションを有効にする必要があります。TW-42818(英語)

9.0.x から 9.1 への変更

バンドルされた Ant

バンドルされた Ant ディストリビューションは、1.8.4 から 1.9.6 にアップグレードされました。バンドルされた Ant を使用する Ant ビルド手順は、サーバーのアップグレード後に Ant の別のバージョンを使用することに注意してください。Ant 1.9.6 は少なくとも Java 1.5 を必要とするため、Ant を使用して Java 1.4 で実行しているビルドは機能しなくなります。

MSTest ランナーを Visual Studio Tests ランナーに変換

MSTest ランナーは VSTest コンソールランナー(英語)(以前は別のプラグインとして提供されていました)とマージされて Visual Studio テストランナーになります。TeamCity 9.1 にアップグレードした後、MSTest ビルドステップは自動的に Visual Studio Tests ランナーステップに変換されますが、VSTest ステップは変更されないことに注意してください。

MSTest インストールエージェントのプロパティ

TeamCity エージェントは、インストールされている MSTest を自動的に検出し、system.MSTest.N.N システムプロパティ内の場所を公開するために使用されます。

TeamCity 9.1 以降、ロケーションは teamcity.dotnet.mstest.N.N 構成パラメーターを介して公開されます。プロパティの使い方を簡単に変更できない場合は、TW-41845(英語) で回避策を確認してください。

入れ子になったテスト報告

以前は、TeamCity はサービスメッセージを使用して、あるテストが別のテスト内から報告されていた場合をサポートしていました。TW-40319(英語) の修正後、別のテストを開始すると、現在開始されているテストは同じ「フロー」で終了します。他のテスト内からテストを報告するには、ネストしたテストサービスメッセージに別の flowId を指定する必要があります。

REST API

REST API はバージョン 9.1 を使用します。以前のバージョンの API は、/app/rest/9.0/app/rest/8.1/app/rest/7.0/app/rest/6.0 の URL で引き続き利用できます。

ビルドを探す
概要(tl; dr): 一部のビルドフィルタリングルールには微妙な変更があります。最も重要なのは、ビルド ID で検索したときに 404 の代わりにキューに入れられたビルドが返されるようになり、「プロジェクト」ロケーターディメンションの意味が再帰的でないように変更されたことです。また、「failedToStart:any」ロケーターディメンションが指定されるまで、ビルドの開始に失敗したことは含まれなくなりました。

詳細:
影響を受けるリクエスト: / app / builds / <locator> ...、/ app / builds ? locator = <locator>、/ app / buildTypes / <btLocator> / builds およびその他のビルドロケーター

ロケータ: id:<番号> または taskId:<番号>

  • 以前は、一致するビルドがキューに入っているビルドであった場合、404(未検出)が返されました

  • キューに入れられたビルドが返される

ロケータ: プロジェクト: <id> ...

  • 以前は、プロジェクトのビルド構成に属するすべてのビルドとそのすべてのサブプロジェクト(再帰的)が見つかりました

  • 指定されたプロジェクトのビルド構成に属するビルドのみが見つかりました。再帰的にビルドを見つけるためには、"ffectedProject:<id> " を使用してください。寸法。これにより、使用方法がビルドタイプロケータと一致するようになります。

ロケータ: タグ: <テキスト>

  • 以前は、"<text>" が ":" 文字を使用していたとき、"<text>" 全体をタグ名として扱うために使用されていました。

  • これで "<text>" はネストしたロケータとして解析されます。":" 文字を含むタグを検索するには、ロケーター "tag:(name :( <tag>))" を使用する必要があります。

ロケータ: <テキスト>

  • 以前は、<テキスト> が数値ではない場合、応答は 400(不正要求)で、"LocatorProcessException: 無効な単一値: '<テキスト>' です。数値にする必要があります " でした。メッセージ。

  • サーバー上のすべてのビルド間でビルド番号による検索が実行されるようになりました(これは運用サーバーでの使用はお勧めできません)。ビルドが見つからない場合 404(Not found)応答が返される

ロケータ: id:<番号>、xxx:yyyy

  • 以前は、ビルドは ID "<number>" で見つかりました。他のディメンションは無視されました

  • id で見つかったビルドが他のディメンションと一致しない場合、応答は 404 になります (未検出)

ロケータ: agent:<agentLocator>

  • 以前は <agentLocator> がそのまま使用され、デフォルトは適用されませんでした。(許可されていないエージェントは特に除外されるまで含まれていました)

  • <agentLocator> は / app / rest / agents request と同じ動作になりました: 不正なエージェントはデフォルトで除外されます

プロジェクトを探す
404 エラーを返すために使用される名前でプロジェクトを検索すると、いくつかのプロジェクトが一致しました。見つかった最初のプロジェクトを返します。

ビルドのアーティファクト
/ app / rest / builds / <locator> / artifacts / * リクエストを介してビルドアーティファクトをリストする際に修正されたいくつかのバグがあり、リクエストの結果に微妙な変化を引き起こす可能性があります。応答に依存している場合は、新しい動作を確認してください。最も重要な変更は次のとおりです。

  • URL 部分で指定された初期パスは現在のロケータ値なしで検索され、ディスク上にそのようなアーティファクトがなくなるまで 404 応答を生成しません。

  • デフォルトでは、アーカイブはディレクトリとして扱われません(子要素を持たない)。アーカイブをディレクトリとして扱うには、"browseArchives:true" を指定します。("recursive:true" モードでは、1 レベルのアーカイブのみがディレクトリとして扱われます。)

エージェント
システムに認識されていない(削除された)エージェントの ID は「-1」でした。現在、「id」、「pool」、その他のいくつかのエントリは、そのようなエージェントには含まれていません。

Xcode 7 のサポート

Xcode 7 用の実験的サポートが追加されました。

課題トラッカーの統合

Due to API changes, third party issue trackers integration plugins might not be compatible with TeamCity version 9.1. Old plugins will not work and will report "java.lang.NoSuchMethodError: jetbrains.buildServer.issueTracker.AbstractIssueProviderFactory.<init>(Ljetbrains/buildServer/issueTracker/IssueFetcher;Ljava/lang/String;)V" error in teamcity-server.log log (more details in the issue(英語) ). If you observe such errors, please contact the plugin authors(英語). If you are the author of affected plugin, please refer to the related notes in オープン API の変更(英語)

9.0.4 から 9.0.5 への変更

特筆すべき変化はありません。

9.0.3 から 9.0.4 への変更

特筆すべき変化はありません。

9.0.2 から 9.0.3 への変更

特筆すべき変化はありません。

9.0.1 から 9.0.2 への変更

特筆すべき変化はありません。

9.0 から 9.0.1 への変更

既知の問題

TeamCity 9.0 でメタランナーを使用するプロジェクトのバージョン対応設定を有効にしている場合、アップグレード時および設定 VCS ルートへのコミット後に、メタランナーはサーバーから削除されます。回避策は、メタランナーの定義を手動で設定リポジトリにコミットすることです。関連号: TW-39519(英語)

Oracle 10.x JDBC ドライバはサポートされなくなりました

Oracle 10.x JDBC ドライバーで各国語文字セット(nvarchar)のサポートが欠落しているため、TeamCity 9.0.1 は Oracle JDBC ドライバーを最新バージョンにアップグレードするよう要求します。サポートされている Oracle JDBC ドライバの最小バージョンは 11.1 です。

8.1.x から 9.0 への変更

既知の問題

  • 「.teamcity」ディレクトリにメンションするカスタムアーティファクトクリーンアップルールが構成されている場合、クリーンアップ手順によりビルドログを削除できます。アップグレードの前にビルドログのバックアップがあることを確認し、「。teamcity」を使用してすべてのカスタムアーティファクトクリーンアップルールを削除します。関連問題: TW-40042(英語) この問題は、9.0.3 リリースで修正されています。

  • TeamCity で Microsoft SQL Server データベースを使用している場合、スケジュールされたクリーンアップバックグラウンドの実行後、TeamCity UI ページはサーバーが再起動するまでロックできます。詳細については、TW-39549(英語) を参照してください。この問題は、9.0.2 リリースで修正されています。

  • サーバーで LDAP 認証を使用していて、サーバーでログイン試行が多い場合(たとえば、アクティブな REST 使用スクリプトがある場合)、OutOfMemory エラーが発生し、サーバーの再起動が必要になる可能性があります。この問題(英語)を修正した LDAP プラグインのインストールを検討してください。この問題は 9.0.1 リリースで修正されています。

  • 大規模な Maven プロジェクトがある場合、ビルドが OutOfMemoryError で失敗することがあります。これは、バックエンドの組み込み Maven がメモリフットプリントが大きい 3.2.3 に更新されたことが原因です。ビルドエージェントのメモリ制限(英語)を増やすことを検討してください関連する問題: TW-41052(英語)

XML 設定ファイル内の UUID

TeamCity 9.0 以降、ディスクに保存されたプロジェクトの XML 設定定義、ビルド構成、VCS ルートには、人間が読み取れない一意の ID(uuid)が保存されています。これらの ID は自動的に生成され、グローバルに一意であると見なされます。設定ファイルのコピーでは、エンティティの id(ファイル名)と名前(兄弟間で)を一意にするだけでなく、ファイルからその uuid を削除する必要があります。TeamCity は新しい uuid を自動的に生成します。

ログストレージを構築する

TeamCity データディレクトリに保存されている内部形式のビルドログの場所が変更されました。内部形式のビルドログファイルは、隠しビルドアーティファクトに保存されるようになりました。名前は、system/messages/CHyy/xxyy.* から system/artifacts/<PROJECT EXTERNAL ID>/<BUILD CONFIGURATION NAME>/xxyy/.teamcity/logs/buildLog.* に変更されました。

古いビルドログは、TeamCity サーバーの起動時に新しい場所に移行されます(TW-37362(英語))。この移行を回避するには、サーバーの起動teamcity.skip.logs.migration 内部プロパティを設定する必要があります。

アップグレード後に再インデックス作成

9.0 より前のバージョンからのアップグレード後の最初のサーバー始動時に、サーバーは検索機能および NuGet フィードのビルドを目的として、すべてのビルドを再索引付けします。インデックス作成中は、一部のビルドは検索結果および NuGet フィードで利用できなくなります。サーバーは、インデックス作成中にパフォーマンスの低い方法で動作することもあります。 teamcity-server.log には対応するロギングがあります。インデックス作成の終了時には、ログに "BuildIndexer(検索) - 再インデックス作成の終了 " と "BuildIndexer(メタデータ) - 再インデックス作成の終了 " の行があります。

課題追跡システムとの統合

TeamCity 9.0 以降、課題追跡システムは、グローバルなサーバー全体の設定ではなくプロジェクトレベルで設定されます。サーバーのアップグレード時には、既存のすべての課題追跡システムの統合がルートプロジェクトに移動されます。これにより、サーバー上のすべてのプロジェクトに引き続きアクセスできるようになります。

WebSocket 接続とプロキシサーバー

9.0 以降、TeamCity は、UI の更新のためにブラウザーとサーバーの間に WebSocket 接続を確立しようとします。TeamCity Web UI の前にプロキシサーバー(nginx など)がある場合は、プロキシが WebSocket 接続をサポートするように正しく構成されていることを確認してください。

プロキシの設定が誤っているか、WebSocket プロトコルをサポートしていない場合、TeamCity システム管理者にサーバーヘルス項目が表示されます。この場合、TeamCity は以前と同じように UI の更新に単純な古いポーリングを使用します。

REST API

REST API はバージョン 9.0 を使用します。以前のバージョンの API は、/app/rest/8.1/app/rest/7.0/app/rest/6.0 の URL で引き続き利用できます。

  • bean を変更します。webLink 属性は、他の Bean と一致するように webUrl に名前変更されます(TW-34398(英語))。

  • 一部の Bean の空のコレクションを表すサブ要素は、応答に含まれなくなりました(以前は XML の空のタグとして含まれていました)。

  • ビルドの changes 要素はデフォルトでは "count" 属性を含みません(パフォーマンス上の理由から)、count はまだ次のように fields パラメーターを提供することで含めることができます。"fields = $ long、変更(件数、href)"

  • /app/rest/agents リクエストはデフォルトですべての許可されたエージェントを返すようになりました (無許可の接続エージェントも含む)

  • キューに入れられたビルドは、taskId 属性の代わりに id 属性を持つようになりました (TeamCity 9.0 以降の新しいビルドでも同じです)

タグ関連の変更を構築する
/app/rest/builds/<buildLocator>/tags ビルド要求は別の XML を返すようになりました: <tags><tag>TAG</tag></tags> の代わりに <tags count="1"><tag name="TAG"/></tags>
同じことが /app/rest/buildTypes/<buildTypeLocator>/<buildTypeLocator>/buildTags リクエストにも当てはまります。
構造の同じ変更は、ビルドのエンティティにネストされた「タグ」要素にも適用されます。

タグを作成するには、プレーンテキストのタグ名を app/rest/builds/<buildLocator>/tags URL に投稿する古い方法があります。
POST または PUTXML または JSON リクエストを URL に送信する場合、新しい XML 形式が使用されます( <tag>TAG</tag> ではなく <tag name="TAG"/></tags> )。

ビルド内で同じ名前のテストを処理する

TeamCity 9.0 では、同じビルド内の同じ名前の複数のテストは、呼び出し回数を持つ単一のテストと見なされます。これらのテスト実行のいずれかが失敗した場合、ビルド全体でテスト全体が失敗したと見なされます。関連する問題は TW-24212(英語) です。

この変更により、同じテストに対して複数の実行があるビルドでテスト番号カウンターが削除されます。ビルドのテスト番号に依存するビルド失敗条件がある場合、この変更はあなたに影響を与える可能性があります。

テストを別々のものとして扱う必要がある場合は、テストスイートで別の名前で実行するか、テスト / 実行ロジックを変更して TeamCity に表示される完全なテスト名を変更することを検討してください。

データベース関連の変更

テキストフィールドの各国語キャラクタセット(nchar、nvarchar、nclob 型)は、TeamCity で使用される MS SQL データベースでサポートされるようになりました。jTDS JDBC ドライバは nchar および nvarchar 文字をサポートしていないため、Microsoft のネイティブ JDBC ドライバを使用することをお勧めします。まだ jTDS を使用している場合は、移行してください。

アップグレードして通常の動作ステータスに入ると、TeamCity はバックグラウンドプロセスを開始して、エントリを vcs_changes データベーステーブルから vcs_change テーブルに移動します。このプロセスは透過的であり、通常どおりサーバーでの作業を続行できます。サーバーのパフォーマンスへの影響はごくわずかであり、影響を受けるロジックはプロジェクトのインポート機能のみです(プロセスの補完後に作成されたバックアップでのみ使用することをお勧めします)。プロセスの進行状況は、「TeamCity は現在、データベース内の VCS 関連データを最適化してバックアップ / 復元のパフォーマンスを向上させています」というメッセージとともに、サーバー管理のバックアップセクションで確認できます。
もう 1 つの重要な点は、データのコピーによって raw データベースストレージのサイズが大きくなることです。
これがケースの問題である場合(たとえば、データベースサイズ制限が設定されている Microsoft SQL Server データベースの場合)、アップグレード前にデータベースサイズ制限が現在のサイズの 2 倍であることを確認することをお勧めします。VCS 変更の移行プロセスが終了した後、データベース固有の手順を実行して、実際に保存されているデータと一致するようにストレージを縮小することができます。

VCS ルート関連の変更

Git および Mercurial の VCS ルートは、新しい VCS ルート用にサーバー上のカスタムクローンパスを指定する機能を提供しなくなりました。この機能が必要な場合は、次の内部プロパティを git と mercurial のそれぞれの true に設定します: teamcity.git.showCustomClonePathteamcity.hg.showCustomClonePath

Visual Studio アドイン

ReSharper Ultimate の一部としてインストールされた TeamCity アドインは、バンドル前の製品バージョン(9.0 より前の TeamCity および ReSharper、3.0 より前の dotCover、6.0 より前の dotTrace)を削除します。

その上、8.1 バージョンによって提供される設定を使用しません。TeamCity サーバーからダウンロードした従来のアドインは、以前のバージョンの設定を使用できます。

その他

Java Web の開始インストールパッケージによる TeamCity エージェントのインストールは利用できなくなりました。

8.1.1 から 8.1.4 への変更

特筆すべき変化はありません。

8.1 から 8.1.1 への変更

コマンドラインランナー

8.1 で導入された動作の変更(下記参照)は修正されました。TeamCity 8.1 で作成 / 変更された "Executable with parameters" オプションを使用しているコマンドラインランナーは、アップグレードに伴う動作の変更を公開することができます。推奨される方法は、コマンドラインランナーで「実行可能パラメーター」の代わりに「カスタムスクリプト」オプションに切り替えることです。

VSTest.Console ランナー用の個別ダウンロード

VSTest コンソールランナーは TeamCity にバンドルされなくなり、個別のプラグインとして利用できるようになりました。ダウンロードの詳細については、プラグインページ(英語)を参照してください (英語)

8.0.6 から 8.1 への変更

統合セキュリティを備えた MS SQL データベースの作成に関する既知の問題

TeamCity を新しくインストールし、データベース設定 UI を使用して統合セキュリティを備えた MS SQL データベースを作成すると、エラーが発生することがあります。次のバグ修正で解決する予定ですが、次の回避策を使用してください。

  1. エラーを受け取ったら、TeamCity サーバーを停止します。

  2. TeamCity サーバーを起動します。

  3. データベース構成画面で、必要な情報を入力します。リフレッシュボタンを使用しない指定された情報が正しいことを確認してください。

  4. 設定手順を続けます。

何らかの理由で上記の回避策で問題が解決しない場合は、次の手順を実行します。

  1. 統合セキュリティなしで、TeamCity サーバーを起動し、新しいデータベースの作成を承認し、ログインとパスワードで MS SQL アクセスを設定します。

  2. TeamCity が正しく機能していることを確認してください。

  3. TeamCity サーバーを停止します。

  4. 外部データベースの設定ファイルを変更します。統合セキュリティを使用するように MS SQL 接続文字列を設定し、ログインとパスワードを削除します。

  5. TeamCity サーバーを再起動してください。

VSTest.Console ランナーの既知の問題

TeamCity 8.1 で最初に登場した新しい "VSTest.Console" ランナーは実験的な状態であり、現時点では本番用にはお勧めできません。デフォルトでは TeamCity 8.1.x には含まれていません(別のダウンロードとして入手可能になるでしょう)。

PowerShell ランナーの既知の問題

PowerShell ランナープラグインは 8.1 で壊れています。修正が利用可能です。問題コメント(英語)の指示に従ってください。

コマンドラインランナーの既知の問題

Command line runner using "Executable with parameters" option can process quotes (") and percentage signs (%) in a bit different way then in previous TeamCity versions (see details in the issue(英語) ). To switch back to the previous (8.0) behavior you may specify command.line.run.as.script=false configuration parameter in a build configuration or in a project. The issue is fixed in 8.1.1.
The recommended approach is to switch to "Custom script" option instead of "Executable with parameters" in command line runner.

メモリ設定

まだ 64 ビット JVM に切り替えがなく、サーバーに -Xmx1300 メモリ設定を使用し、サーバーが Windows 上で実行されている場合は、「ネイティブメモリの割り当て (malloc) が失敗しました」という JVM クラッシュが発生する可能性があるため、-Xmx1200 に設定を減らすことを検討してください。詳細については、推奨メモリ設定を参照してください。

アクションメニュー

Some actions has moved under the "Actions" button available at the top-right of the page, near Run button.
These include:"Label this build sources" on Changes tab of a build,
"Pause", "Copy", "Move", "Delete", "Associate with Template", "Extract Template", "Extract Meta-Runner" on build configuration settings administration page,
"Copy", "Move", "Delete", "Archive", "Bulk edit IDs" on the プロジェクト設定 administration page.

デフォルトで Create Maven ビルド構成は使用できません

アクション " Maven ビルド構成の作成 " 使用できなくなりました。その機能のほとんどは、URL からのプロジェクトの作成および URL ページからの VCS ルートの作成によってカバーされます。

GroovyPlug プラグインの triggerBy パラメーター

プラグイン(英語)によって追加されたプラグインによって提供される build.triggeredBy および build.triggeredBy.username 構成パラメーターは、それぞれ teamcity.build.triggeredBy および teamcity.build.triggeredBy.username の名前でプラグインなしで使用できるようになりました。プラグインのものを使用した場合は、設定で後者のパラメーターセットに移行することを検討してください。

共有リソース構築機能

カスタム値を使用してビルドがリソースのすべての値をロックする場合、これらの値はビルドパラメーターのロック値として提供されます。対応する号: TW-29779(英語)

TeamCity ディスクスペース監視

次の内部プロパティは、TeamCity サーバーマシンの空きディスク容量のしきい値を定義します。

  • teamcity.diskSpaceWatcher.threshold をデフォルトで 500 Mb に設定すると、TeamCity Web UI のすべてのページに警告が表示されます。

  • デフォルトで 50 MB に設定された teamcity.pauseBuildQueue.diskSpace.threshold は、構築キューを一時停止します。 teamcity.diskSpaceWatcher.softThreshold プロパティは削除されました。

PowerShell

PowerShell プラグインは、スクリプトを実行するときに、-Version コマンドライン引数として UI で指定されたバージョンを使用するようになりました。対応する号: TW-33472(英語)

REST API

API の最新バージョンは変更されていません。以下に詳述する API に変更がありますが、それでも「8.0」です。これが RESTAPI の使用に不便であると思われる場合は、対応する問題(英語)にコメントしてください。

REST API リクエストの応答で返されるエンティティは、空の値またはデフォルト値を持つ属性 / 要素を除外するようになりました。これは、"false" 値と空のコレクションを持つブール値フィールドに関連します。推奨される方法は、クライアントコードが存在しないブール型の属性 / 要素の値として「false」を想定することです。

buildType ノードの「projectName」に、プロジェクトの短い名前ではなく、完全なプロジェクト名(親プロジェクトの名前を含む)が含まれるようになりました。

ビルドの一覧で、"startDate" 属性が "build" ノードに含まれなくなりました。フルビルドのデータ表現に合わせるために、属性ではなく要素になりました。REST API の使用箇所が影響を受ける場合は、道(英語)を調べてビルドのリストを求める要求でその要素を取得してください。

リクエスト / app / rest / buildTypes / XXX / parameters / YYY と / app / rest / projects / XXX / parameters / YYY は "text / plain" と "application / xml" レスポンスをサポートします。プレーンテキストの応答を取得するには(8.1 より前でサポートされている唯一の方法でした)、リクエストに "Accept:text / plain" ヘッダーを指定する必要があります。

VCS ルートのパスワードプロパティは、値なしで応答に含まれるようになりました。

CCTray フォーマット XML(app/rest/cctray/projects.xml)には、一時停止ビルド構成は含まれていません。

実験的要求への応答 /app/rest/buildTypes/XXX/investigations は形式を変更し、テストと問題調査をカバーするための追加フィールドを取得しました。削除されたサブアイテムを含めるための内部プロパティ rest.beans.buildTypeInvestigationCompatibility があります。内部プロパティを使用する必要がある場合は、サポートメールでお知らせください。

Eclipse プラグイン

Subversion 1.4-1.6 のサポートを終了しました。現在、Subversion 1.7-1.8 作業コピー形式のみがサポートされています。

8.0.5 から 8.0.6 への変更

特筆すべき変化はありません。

8.0.4 から 8.0.5 への変更

特筆すべき変化はありません。

8.0.3 から 8.0.4 への変更

最初のクリーンアップ

サーバーに多数のビルドが存在する場合、サーバーのアップグレード後の最初のクリーンアップには、通常よりも少し時間がかかる場合があります。その後のクリーンアップは、以前のバージョンよりも少し高速に実行されます。

8.0 から 8.0.3 への変更

特筆すべき変化はありません。

7.1.x から 8.0 への変更

プロジェクトおよびビルド構成 ID

このバージョンでは、プロジェクトおよびビルド構成にユーザー割り当て可能な ID が導入されました。この新しい ID は、少なくとも次の項目で内部 ID(projectN および btNNN)の代わりに使用されるようになりました。

  • Web ページの URL とアーティファクトのダウンロード

  • REST API

  • プロジェクト ID は、TeamCity 8.0 より前に使用されていたプロジェクト名の代わりに、<TeamCity Data Directory>\system\artifacts のサーバー上のディレクトリ名にも使用されています。

上記のいずれかを使用した場合は、変更の影響を受けるかどうかを確認してください。
識別子で ID の詳細を参照してください。

アップグレード時に、すべてのプロジェクトは名前に基づいて自動的に生成された ID を取得します。
ビルド構成 ID は、内部(btNNN)ID と等しくなるように設定され、後で ID を再生成または一括編集 ID アクションを介して管理 UI から変更できます。

プロジェクトの名前とビルド構成は、サーバー全体で一意ではなくなり(直接の親プロジェクト内でのみ一意)、ディレクトリ名またはファイル名でこれらを使用した場合に関連する可能性がある任意の記号を含めることができます。

ディスク上のプロジェクト設定フォーマット

< TeamCity Data Directory >/config 下のディスク上のプロジェクト設定ストレージのフォーマットが変更されます。
ツールを使用して project-config.xml ファイルを読み取ったり更新したりした場合は、ツールを更新する必要があります。ツールがフォーマットの変更によって大きな影響を受けないように、REST API または TeamCity オープン API(Java)を使用して変更を加えることをお勧めします。

構成テンプレートの構築

バージョン 8.0 では、ビルド構成テンプレートはプロジェクト階層をサポートし、TeamCity は新しい規則を使用します。

  • TeamCity 管理 UI はテンプレートの使用を現在のプロジェクトとその親からのものだけに制限します。プロジェクトまたはビルド構成をコピーすると、ターゲットプロジェクトまたはその親のいずれにも属していないテンプレートが自動的にコピーされます。

  • テンプレートが現在のプロジェクトまたはその親の 1 つに属していない場合、TeamCity はビルド構成をテンプレートにアタッチすることを許可しなくなりました。

  • バージョン 8.0 より前では、あるプロジェクトのビルド構成から関連のないプロジェクトにテンプレートを抽出したり、あるプロジェクトのビルド構成を別のプロジェクトのテンプレートに関連付けることができました。TC 8.0 へのアップグレード後、そのようなテンプレートは現在のプロジェクトではアクセスできなくなります。無関係なプロジェクトからビルド構成テンプレートを再利用するには、共通の親プロジェクト(またはグローバルに使用可能にする場合はルートプロジェクト)に手動で移動することをお勧めします。

JVM 起因のエージェントパラメーター (os.arch など)

エージェントは、エージェント JVM( system.os.arch, system.os.name, system.os.version, system.user.home, system.user.name, system.user.timezone, system.user.language, system.user.country, system.user.variant, system.path.separator, system.file.encoding, system.file.separator )に由来するシステムプロパティを報告しなくなりました。前述のすべてのパラメーターは、代わりに teamcity.agent.jvm. プレフィックスを持つ設定パラメーターとして報告されるようになりました。いずれかのパラメーターを使用した場合は、必ず新しい値に更新してください。

IntelliJ IDEA プロジェクトランナー

IntelliJ IDEA プロジェクトランナーは、IntelliJ IDEA の外部 make ツールを使用してプロジェクトをビルドします。このツールを使用するには Java 1.6 が必要であるため、IntelliJ IDEA プロジェクトランナーでは Java 1.6 も(少なくとも)必要になりました。

機能ブランチを使用したビルド構成のクリーンアップ

機能ブランチを使用したビルド構成は、ブランチごとにクリーンアップ規則を処理するようになりました。これにより、クリーンアップ中に以前のバージョンよりも多くのビルドが保持される可能性があります。参照してください詳細を。

Team Foundation サーバー統合

TFS は、TFS 操作に Team Explorer 2010(両方がインストールされている場合)よりも Team Explorer2012 を優先するようになりました。

YouTrack との互換性

JetBrains YouTrack を使用し、その TeamCity 統合機能を使用する場合、YouTrack バージョン 4.2.4 以降のみが TeamCity 8.0 と互換性があることに注意してください。
TeamCity 8.0 で動作するために以前の YouTrack バージョンが必要な場合は、お知らせください

REST API

外部 ID プロジェクト / ビルドタイプ / テンプレートの新しい外部 ID に関連する API の変更、およびその他の変更があります。
TeamCity 7.1 と互換性のある古い API は、引き続き「/app/rest/7.0」URL で提供されます。

プロジェクト、ビルド構成、またはテンプレート( .../app/rest/projects/id:XXX.../app/rest/buildTypes/id:XXX など)に "id" を持つロケータを含む URL を使用した場合は、ロケータを次のいずれかに更新してください。

  • (推奨) "id:EXTERNAL_ID"(Web UI の URL または .../app/rest/projects/internalId:OLD\_ID/id へのリクエストで外部 ID を取得できます)

  • 内部、外部の ID、または名前でエンティティを見つけるには、"ANY_ID" だけを使用します(注意して使用してください)。期待以上のものを見つけることができます)

  • "internalId:INTERNAL_ID" 内部 id によってエンティティを検索する "/app/rest/7.0/" URL 接頭辞を "/app/rest/" の代わりに使用して、ビルド完了トリガープロパティを除き内部 ID を使用する 7.0 バージョンの REST API を操作することもできます。

また、内部プロパティ rest.compatibility.allowExternalIdAsInternal=true を設定して互換モードをオンにし、id:xxx ロケーターも内部 ID で検索するようにすることができます。これは TeamCity の将来のバージョンでは削除される予定であり、使用することはお勧めできません。

その他の変更
ビルドのリクエスト "... / builds / <locator> / ... "および"... / builds ? locator = <locator>" は、デフォルトでは個人用およびキャンセルされたビルドを返さなくなりました。これらを含めるには、ロケーターに必ず「、personal:any、canceled:any」を追加してください。

ビルドエンティティの「relatedIssues」要素には、関連する問題の完全なリストが含まれなくなりました。これには「href」属性のみがあり、その値を使用して、別のリクエストを介して関連する問題を取得できます。
互換性のために「relatedIssues」ノードを返すために true に設定できる内部プロパティ「rest.beans.build.inlineRelatedIssues」もあります。詳細については、TW-20025(英語) を参照してください。また、「... / builds / xxx / related-issues」URL の名前が「... / builds / xxx / relatedIssues」に変更されます。

「source_buildTypeId」プロパティは、スナップショットおよびアーティファクトの依存関係ノードから削除されます。代わりに、「source-buildType」サブ要素がビルドタイプへの参照とともに追加されます。
依存関係の作成は「source_buildTypeId」プロパティで引き続きサポートされていますが、非推奨です。内部プロパティ「rest.compatibility.includeSourceBuildTypeInDependencyProperties」があり、これを true に設定して、「source_buildTypeId」プロパティを元に戻すことができます。

バージョン 8.0 では、VCS ルートはプロジェクト階層をサポートします。

  • VCS ルートを作成するときは、project 要素を常に指定する必要があります。この要素は、プロジェクトを指定するための locator 属性をサポートしています。

  • shared 属性は VCS ルートから削除されます。アップグレード後、そのような VCS ルートはルートプロジェクトに(「_Root」ID で)付加され、グローバルに利用可能になります。

  • プロジェクトをコピーして構成をビルドするときに、shareVCSRoots 属性はもう存在しません。VCS ルートをプロジェクトで使用可能にして設定を構築するには、VCS ルートを親 / ルートプロジェクトに移動してからコピーを続行します。

組織 / 設定共有構造に対応するプロジェクト階層を作成し、VCS ルートを最もネストされた包括的プロジェクトに移動することをお勧めします。その後、ユーザーはプロジェクト内で「VCS ルートの作成 / 削除」ロールを付与され、VCS ルートを編集できるようになります。ユーザーが「プロジェクトの編集」権限を持つプロジェクトで使用されている場合にのみ、VCS ルートを編集できることに注意してください。

ビルド構成テンプレートノードの「template」属性は「templateFlag」に名前が変更されます。

/ users / <locator> / roles および / userGroups / <locator> / roles の PUT は、必要に応じてロールのリストを受け入れ、単一のロールを受け入れて追加するのではなく、既存のロールを置き換えます。

何も返さなかった PUT および POST リクエストの多くは、作成されたエンティティを返すようになりました。

オープン API の変更

参照してください詳細を (英語)

共有リソースプラグイン

TeamCity 7.1.x で共有リソースプラグイン(英語)を使用した場合は、バンドルされているため、必ず削除してください。アップグレード手順(英語)を参照してください(英語)

キューマネージャープラグイン

QueueManager プラグイン(英語)を使用した場合は、バンドルされているため、必ず削除してください。アップグレード手順(英語)を参照してください (英語)

同梱の Maven

TeamCity にバンドルされた Maven は、バージョン 3.0.5 にアップグレードされました。

エージェントからサーバーへの HTTPS 接続

エージェントが HTTPS プロトコルで TeamCity サーバーに接続していて、アップグレード後にエージェントが以下のようなエラーメッセージで接続に失敗した場合: javax.net.ssl.SSLHandshakeException: 致命的なアラートを受信しました: handshake_failure

それから、Tomcat SSL コネクターの設定を変更する必要があります。すなわち、SSL コネクターに次の属性を追加して TeamCity サーバーを再起動します。sslEnabledProtocols = "TLSv1、SSLv3、SSLv2Hello"

この問題は、サーバーが Java 1.7 のもとで動作している場合にのみ発生します。

関連事項:

7.1.4 から 7.1.5 への変更

teamcity.build.branch パラメーターのセマンティクスが変更されました。http://youtrack.jetbrains.com/issue/TW-23699#comment=27-448002(英語) を参照してください

7.1.3 から 7.1.4 への変更

特筆すべき変化はありません。

7.1.2 から 7.1.3 への変更

特筆すべき変化はありません。

課題追跡システムで、バージョンの既知のリグレッション(英語)の最新リストを確認してください。

7.1.1 から 7.1.2 への変更

hg サーバーサイドチェックアウトで起こりうる問題
7.1.2 リリースには既知の問題があります。TW-24405(英語) は、サーバー側のチェックアウト、ラベル付け、またはファイルコンテンツの表示が Mercurial リポジトリで使用されたときに再現できます。「abort: 宛先 'hg1' は空ではありません」というメッセージのエラーが発生した場合は、問題に添付されているパッチをインストールしてください。

その他の既知の問題
課題追跡システムで、バージョンの既知のリグレッション(英語)のリストも確認してください。

7.1 から 7.1.1 への変更

特筆すべき変化はありません。

7.0.x から 7.1 への変更

Windows サービス構成
バージョン 7.1 以降、TeamCity は、以前のバージョンのデフォルトの Tomcat サーバーとは対照的に、TeamCity サーバーに独自のサービス折り返しソリューションを使用します。これにより、TeamCity サービスの構成方法(データディレクトリとメモリ設定を含むサーバー起動オプション)が変更され、サービスとコンソールの起動が統合されます。
サーバーの起動プロパティの構成に関する更新されたセクションを参照してください。

Agent Windows サービスは OS 提供の環境変数を使用し始めました。エージェントサーバー(および JVM)が x86 プロセスになると、エージェントは x86 環境変数を報告します。変更はあなたの CPU bitness チェックに影響するかもしれません。報告された環境変数で machine が x64 をサポートしているかどうかを確認する方法については MSDN ブログ(英語)を参照してください。

Windows インストーラーと一緒にインストールされた場合の TeamCity データディレクトリのデフォルトの場所
これは、Windows インストーラーを使用した TeamCity の新規インストールにのみ関連します。既存のインストールをアップグレードしても、既存の設定は保持されます。
Windows インストーラーは、TeamCity データディレクトリのデフォルトの場所として %ALLUSERSPROFILE%\JetBrains\TeamCity の場所を使用するようになりました。TeamCity 7.0 および以前のバージョンでは %USERPROFILE%\.BuildServer でした。

Windows ドメインログインモジュール
TeamCity サーバーが Windows で実行され、Windows ドメインユーザー認証が使用されている場合、TeamCity は別のライブラリ(ワッフル)を使用して Windows ドメインと通信するようになりました。Linux では動作は変更されていません。jCIFS ライブラリがそのまま使用されます。

ntlm-config.properties ファイルで jCIFS ライブラリに特定の設定を指定しない限り、インストールに影響はありません。
アップグレード後に Windows のユーザー名 / パスワードを使用して TeamCity にログインする際に問題が発生した場合は、詳細をお知らせください。それまでの間、古い jCIFS ライブラリの使用に切り替えることができます。このために、teamcity.ntlm.use.jcifs=true 行を内部プロパティファイルに追加します。
jCIFS ライブラリアプローチは TeamCity の将来のバージョンで廃止される可能性があるため、それなしで実行できる場合は、プロパティの指定は推奨されないことに注意してください。

Git および Mercurial のチェックアウトディレクトリの変更
Git または Mercurial の VCS ルートを持ち、デフォルトのチェックアウトディレクトリを使用するビルド構成は、アップグレード時にクリーンチェックアウトを実行します。クリーンチェックアウトは、変更されたデフォルトのチェックアウトディレクトリ名によってトリガーされます。それ以降のビルドでは、チェックアウトディレクトリがより積極的に再利用されます(異なるブランチを使用しているが、同じ VCS ルートを使用しているすべてのビルドは同じディレクトリを使用します)。これは、エージェント側とサーバー側のチェックアウトに影響します。

Perforce エージェントチェックアウトワークスペース名の変更
Perforce エージェント側のチェックアウトを使用したビルド構成は、サーバーのアップグレード後に 1 回クリーンチェックアウトを実行します。これは、自動生成された Perforce ワークスペースの名前の変更に関連しています。

SVN 改訂フォーマット
外部リポジトリで検出された変更の場合、SVN リビジョンの形式は NNN_MMM:EXTUUID_CHANGEDATE になります。NNN- メインリポジトリのリビジョン、MMM- 外部リポジトリのリビジョン、EXTUUID- 外部リポジトリの UUID、CHANGEDATE- タイムスタンプを変更します。この変更は、何らかの理由で最後のビルド変更のリビジョンを使用するプラグイン / REST API クライアントに影響を与える可能性があります。

Eclipse IDE プラグインの互換性
TeamCity 7.1 以降、Eclipse バージョン 3.3(Europa)は TeamCity Eclipse プラグインでサポートされなくなりました。Eclipse 3.8 および Eclipse 4.2(Juno)がサポートされるようになりました。

Microsoft SQL Server が外部データベースとして使用されている場合のデフォルトスキーマ
バージョン 7.1 以降、TeamCity は、データベースサーバーの任意のスキーマのテーブルを処理できる以前のバージョンとは異なり、単一のデータベーススキーマでのみ機能します。

TeamCity 関連のテーブルは、データベースに接続するために TeamCity によって使用されるデータベースユーザーのデフォルトテーブルとして設定されているデータベーススキーマに配置されているはずです。

この変更により、TeamCity サーバーがデータベースに接続するために使用するユーザーのデフォルトスキーマを設定するためにデータベースの再設定が必要になる場合があります。

アップグレードを実行する前に、すべての TeamCity 関連テーブルがデフォルトのユーザーのスキーマにあることを確認してください。(たとえば使用して(英語)「SYS.TABLES」ビューを)

デフォルトのユーザーのスキーマが正しく設定されていない場合、TeamCity は「TeamCity データベースが空か、存在しません。続行すると、新しいデータベースが作成されます」と報告されることがあります。新しい TeamCity の最初の起動時にメッセージ。

ユーザーのデフォルトスキーマを変更するには、「 alteruser(英語) 」SQL コマンドを使用し(英語)ます。

デフォルトのスキーマの説明については、対応するドキュメント(英語)の「デフォルトのスキーマ」セクションを参照してください。

オープン API の変更
参照してください詳細を (英語)

7.0.1 から 7.0.4 への変更

特筆すべき変化はありません。

7.0 から 7.0.1 への変更

HTML レポートタブ URL の変更
ビルドレベルまたはプロジェクトレベルのレポートタブに直接リンクを使用する場合は、アップグレード後に変更(英語)されるため、リンクを更新してください。この変更は、機能の信頼性を高めるために必要です。

6.5.x から 7.0 への変更

(既知の問題)NUnit や他の .NET テストランナーでビルドがハングアップしたりメモリエラーが発生することがある
影響を受けるのは、.Net テストランナー(NUnit、MSTest、MSpec)、TeamCity NUnit コンソールランチャーです。
テストアセンブリへのパスにワイルドカード("*")のないいくつかの深いパスがある場合に再現されます。

目に見える結果: ビルドがハングアップするか、ビルドログの "Starting ... JetBrains.BuildServer.NUnitLauncher.exe" リンクの後に OutOfMemoryException エラーで失敗します。

この問題(TW-20482(英語))は修正されており、修正は次のリリースに含まれる予定です。
修正されたパッチが利用可能です(英語)

Ant ランナーのための最小サポートプロジェクト JDK
このバージョン以降、Ant ランナーでは、ランタイムビルドパーツに JDK 1.4 以上が必要です(以前は 1.3 でした)。これは、プロジェクトでコンパイルまたはテストの実行に JDK 1.3 を使用している場合、TeamCity Ant ランナーを使用できないことを意味します。JDK 1.3 を必要とするプロジェクトでは、代わりにコマンドラインランナーを使用して、「XML レポート処理」ビルド機能を設定し、テストレポートを解析できます。

サーバーとエージェントでサポートされている Java
このバージョン以降、次の要件

  • TeamCity サーバーは、JRE 1.6 以上(以前は 1.5 でした)で実行する必要があります。TeamCity .exe ディストリビューションはすでに適切な Java にバンドルされています。.tar.gz または .war TeamCity ディストリビューションの場合、サーバーを手動でインストールおよび構成する必要がある場合があります。

  • TeamCity エージェントは、JRE 1.6 以上(以前は 1.5)で実行する必要があります。エージェント .exe ディストリビューションは、適切な Java にすでにバンドルされています。.zip エージェントディストリビューションを使用した場合、または TeamCity バージョン 5.0 以前で TeamCity エージェントをインストールした場合は、手動の手順が必要になることがあります。TeamCity 6.5.x を実行する場合は、既存の TeamCity サーバーのエージェントページを確認してください。接続されているエージェントのいずれかが JDK 1.6 未満を実行している場合、ページには黄色の警告が表示されます。

プロジェクト / テンプレートパラメーターの上書き
TeamCity 7.0 では、プロジェクトパラメーターは、テンプレートで定義されたパラメーターよりも優先されます。つまり、プロジェクトに名前と値のあるパラメーターがあり、同じプロジェクトのテンプレートに同じ名前と異なる値のパラメーターがある場合、プロジェクトの値は利用されます。これは TeamCity 6.5 ではそうではなく、テンプレートが anohter プロジェクトに属する場合により柔軟になるように変更(英語)されました。通常どおり、ビルド構成パラメーターの優先度が最も高くなります。

Sybase のサポートは終了しています
このバージョンから、外部データベースとしての Sybase のサポートは、「実験的」状態に戻ります。
この決定の理由は、データベースが TeamCity で積極的に使用されているようには見えず、データベースをサポートするには TeamCity チームの多大な努力が必要であり、そうでなければ製品のより重要な領域の改善に向けることができます。
それでも可能(英語)であるはずですが、Sybase を外部データベースとして使用することはお勧めしません。また、Sybase 関連の問題のサポートを提供する予定はありません。
サポートされている他のデータベースのいずれかを使用することを検討してください。Sybase を使用している場合は、TeamCity をアップグレードする前に別のデータベースに移行してください。

REST API の変更

  • いくつかのオブジェクトは、追加の属性とサブ要素(BuildType、VcsRoot など)を取得しました。解析コードが引き続き機能することを確認してください。/ buildTypes / path:BuildType オブジェクトは runParameters フィールドを削除しました(および / <locator> / runParameters パスも削除されました)。ステップコレクションと / <locator> / Steps / パスを優先します

  • 一部のリソースの単一要素配列の非配列 JSON 表現をもたらすバグが修正(英語)されました。コードが影響を受けるかどうかを確認してください。

  • ビルドオブジェクトでは、"dependency-build" 要素は "snapshot-dependencies" に変更され、revisions / revision / vcs-root は revisions / revision / vcs-root-intance に変更されています(そして現在は解決済みの VCS ルートインスタンスを指しています)。revisions / revision / display-version は "version" に改名されます。

  • buildType オブジェクトでは、「vcs-root」要素は「vcs-root-entries」に名前変更されています。

REST API の旧バージョンは、TeamCity 7.0 の /app/rest/6.0/... URL から入手できます。今後のバージョンの TeamCity では 6.0 プロトコルのサポートが終了する可能性があるため、REST を使用しているコードを更新してください。

サポートされている Tomcat の最小バージョン
TeamCity .war ディストリビューションを使用する場合、Tomcat 5.5 はサポートされなくなったことに注意してください。Tomcat をバージョン 6.0.27 以上に更新してください(Tomcat 7 をお勧めします)。

Swabra

swabra.handle.exe.path および handle.exe.path 構成パラメーターは、エージェントの Sysinternals handle.exe へのパスを提供するためにサポートされなくなりました。詳細はプラグインページを参照してください。

オープン API の変更

jetbrains.buildServer.messages.serviceMessages.BuildStatus のような jetbrains.buildServer.messages.serviceMessages パッケージのクラスは、jetbrains.buildServer.messages.Status クラスに依存しなくなりました。あなたのコードを TeamCity 6.0 - 7.0 と互換性を持たせるために、jetbrains.buildServer.messages.serviceMessages.ServiceMessage#asString メソッドを使うことができます。

ServiceMessage.asString("buildStatus", new HashMap<String, String>() {{   put("text", "Errors found");   put("status", "FAILURE"); }});

オープン API の変更(英語)も参照してください

6.5.4 から 6.5.6 への変更

特筆すべき変更はありません

6.5.4 から 6.5.5 への変更

(6.5.6 の既知の問題の感染).NET Duplicates ファインダーが動作しなくなる可能性があります。パッチは入手可能です。http://youtrack.jetbrains.net/issue/TW-18784#comment=27-261174(英語) を参照してください

6.5.3 から 6.5.4 への変更

特筆すべき変更はありません

6.5.2 から 6.5.3 への変更

特筆すべき変更はありません

6.5.1 から 6.5.2 への変更

Maven ランナー
MAVEN_OPTS の操作が再び変更されました。うまくいけば、6.5.x の反復内で最後になります。(http://youtrack.jetbrains.net/issue/TW-17393(英語) を参照)
これで、TeamCity は次のように動作します。

  1. MAVEN_OPTS が設定されている場合、TeamCity は MAVEN_OPTS から JVM 引数を取ります。

  2. ランナー設定で「JVM コマンドラインパラメーター」が指定されている場合は、MAVEN_OPTS および MAVEN_OPTS はこの値で上書きされ、ネストされた Maven の実行に伝播されますの代わりに使用されます。

6.5 にアップグレードした後に MAVEN_OPTS を使用しないという問題を抱えていて、ビルドを機能させるためにその値を「JVM コマンドラインパラメーター」にコピーする必要があった人々は、今では設定を変更する必要はありません。ビルドは 6.5 または 6.5.1 と同じように機能します。

6.5 から 6.5.1 への変更

(既知の問題を修正)Oracle での長いアップグレード時間と遅いクリーンアップ

6.0.x から 6.5 への変更

(既知の問題)Oracle での長いアップグレード時間と遅いクリーンアップ
最初にアップグレードされたサーバーの起動時に、データベース構造が変換されます。Oracle 外部データベース(TW-17094(英語))を使用する場合、これには長時間(大きなデータベースでは数時間)かかることがあります。これはすでに 6.5.1 で修正されています。

エージェント JVM のアップグレード
このバージョンの TeamCity では、エージェントが使用する JVM の半自動アップグレードが追加されました。エージェントに Java 1.6 がインストールされていて、エージェント自体が引き続き Java 1.5 で実行されている場合、TeamCity はエージェントを Java 1.6. に切り替えるように求めます。必要なのは、Java への検出されたパスが正しいことを確認し、この切り替えを確認することだけです。自動的に行われます。操作はエージェントごとです。エージェントごとに個別に作成する必要があります。TeamCity が Java 1.5. と互換性がない場合があるため、Java 1.6 に切り替えることをお勧めします。新しく選択した java プロセスに同じファイアウォールルールがあることを確認してください。(つまり、サーバーからの接続を受け入れるためにポート 9090 が開かれます)

IntelliJ IDEA カバレッジデータ
TeamCity 6.5 にバンドルされている IntelliJ IDEA カバレッジエンジンによって生成されたカバレッジデータは、IntelliJ IDEA 10.5 + でのみロードできます。カバレッジデータ形式の変更により、古いバージョンの IntelliJ IDEA はサーバーからカバレッジをロードできません。

IntelliJ IDEA 8 はサポートされていません
IntelliJ IDEA のプラグインは IntelliJ IDEA 8 をサポートしなくなりました。

サポートされていない MySQL のバージョン
MySQL 5.1.x のバグ(英語)により、TeamCity は範囲 5.1 - 5.1.48 の MySQL バージョンをサポートしなくなりました。サポートされていない MySQL バージョンが検出された場合、TeamCity は適切なメッセージで開始されません。MySQL サーバーをバージョン 5.1.49 以降にアップグレードしてください。

仕上げビルドのプロパティが表示されます
完成したビルドには、パラメータータブのビルドで使用されるすべてのプロパティが表示されます。これにより、他のビルド(アーティファクトまたはスナップショットの依存関係として使用されるビルド)のパラメーターの名前と値が公開される可能性があります。これが環境で許容できることを確認してください。また、デフォルトで「プロジェクト開発者」のロールが割り当てられている「ビルドランタイムパラメーターとデータの表示」権限を持つタブを表示するユーザーを管理することもできます。

PowerShell ランナー同梱
PowerShell プラグイン(英語)を手動でインストールした場合は、.BuildServer/plugins から削除してください。新しいバージョンが TeamCity にバンドルされています。

設定の場所を変更しました

  • XML テストレポート設定は、ランナー設定から専用のビルド機能に移動されます。

  • スナップショット依存関係を持つビルドに対する「最後のビルド」アーティファクト依存関係は、自動的に専用の「同じチェーンからのビルド」ソースビルド設定に変換されます。

責任は「調査」に変更されます
失敗したビルド構成またはテストに割り当てられた責任は、調査と呼ばれるようになりました。これは、アクションをよりニュートラルにするための用語の変更にすぎません。
TeamCity 調査割り当てアクティビティのメール処理ルールがある場合は、新しいテキストパターンを使用するために更新する必要があるかどうかを確認してください。

REST API の変更
いくつかのオブジェクトには、追加の属性とサブ要素があります(たとえば、ビルドを参照する「startDate」、変更を「個人」にする)。解析コードが引き続き機能することを確認してください。

デフォルト以外のチェックアウトディレクトリのクリーニング
以前のリリースでは、絶対パスを使用してビルドチェックアウトディレクトリを明示的に指定した場合、TeamCity はディレクトリの内容をクリーンアップしてディスク上のスペースを解放しませんでした。
これはもはや当てはまりません。
したがって、チェックアウトディレクトリに絶対パスを指定していて、他のビルドまたはマシン環境のエージェントにディレクトリを存在させる必要がある場合は、system.teamcity.build.checkoutDir.expireHours プロパティを「never」に設定してビルドを再実行してください。カスタムチェックアウトディレクトリの使用は推奨されないことを考慮に入れてください。

system.teamcity.build.checkoutDir.expireHours プロパティの 1 つを使用していて、チェックアウトディレクトリが自動削除されないように "never" に設定されている場合、TeamCity のアップグレード後にディレクトリが一度削除されることがあります。アップグレード後(そして前回のビルドから 8 日以内)にビルド構成でビルドを実行すると、ディレクトリは " 保護された " 動作を維持し、TeamCity によって自動的に削除されません。

空きディスク容量
このリリースでは、ビルド構成プロパティの設定を介してのみ以前は利用可能だった空きディスク容量が UI で公開されます。
古いプロパティは引き続き機能し、優先されますが、削除し、代わりに「ディスク領域」ビルド機能を使用して値を指定することを強くお勧めします。将来の TeamCity バージョンでは、手動で指定されたプロパティの考慮が停止する可能性があります。

コマンドラインランナー
コマンドエコーをオフにする @echo off は、「カスタムスクリプト」ランナーパラメーターによって提供されるスクリプトに追加されます。コマンドエコーを有効にするには、@echo on をスクリプトに追加します。

Windows トレイ通知機能
Windows トレイ通知機能をアンインストールしてから再度インストールして、アップグレードする必要があります。残念ながら、古いバージョンの Windows Tray Notifier の問題のため、自動アップグレードは機能しません。

Maven ランナー

  • 以前の TeamCity バージョンでは、Maven は「mvn」シェルスクリプトを呼び出すことで実行されていました。MAVEN_OPTS でいくつかのパラメーターを指定し、UI でいくつかを指定できます。Maven ビルドランナーは、これら 2 つを連結して独自の MAVEN_OPT を作成しました(%MAVEN\_OPTS%\+jvmArgs )。この場合、あるパラメーターが 2 回指定された場合 -MAVEN_OPTS と UI で、MAVEN_OPTS で指定されたパラメーターのみが有効でした。TeamCity 6.5 から始まり、Maven ランナーは直接 java コマンドを形成します。このアプローチは多くのさまざまな問題を解決しますが、MAVEN_OPTS はもはや有効ではなく、すべての JVM コマンドラインパラメーターは MAVEN_OPTS ではなくビルドランナー設定で指定する必要があることも意味します。

  • Maven リリースビルドの TeamCity 6.0.x の確実な XML レポートを手動でセットアップする必要があった人は、テストがレポートされなかったため、今ではそのことを忘れることができます。TeamCity 6.5 の確実なテストは release:prepare または release:perform ゴールで実行されるため、自動的に検出されます。そのため、ビルド構成設定で確実な XML レポートをオフにすることを忘れないでください。

メール送信設定
アップグレード後にメール送信設定が正しく機能していることを確認してください(管理> サーバー構成> メール通知のテスト接続を使用)。認証が不要な場合は、ログインフィールドとパスワードフィールドが空白であることを確認してください。SMTP サーバーが認証要求を予期していない場合、空白以外のフィールドはメール送信エラーを引き起こす可能性があります。

XML レポート処理
Ant JUnit XML レポートからのテストは、TESTS-xxx.xml レポートを自動的に無視しなくなったため、2 回レポートできます(TW-19058(英語) を参照)。
これを回避するには、*.xml マスクの使用を避け、「TESTS-」で始まる名前のレポートと一致しない TEST-*。xml などのより具体的なルールを指定します。

オープン API の変更
いくつかの戻り値の型では TeamCity オープン API が変更されているため、プラグインが機能し続けるには、新しい TeamCity バージョンに対して再コンパイルする必要がある場合があります。
また、一部の API は非推奨になり、今後のリリースで廃止される予定です。非推奨の API を使用しないようにプラグインを更新することをお勧めします。
オープン API の変更(英語)も参照してください

6.0.2 から 6.0.3 への変更

特筆すべき変更はありません

6.0.1 から 6.0.2 への変更

Maven と XML のテストレポートでエージェントに CPU がかかる
Maven または XML テストレポーターを使用していて、ビルドが CPU を集中的に使用する場合、既知の問題(英語)が重要であることがわかる場合があります。パッチが利用可能で、次のアップデートで修正されています。

6.0 から 6.0.1 への変更

特筆すべき変更はありません

5.1.x から 6.0 への変更

Visual Studio アドインと Perforce
There is critical bug in TeamCity 6.0 VS Add-in when Perforce is enabled. This can cause Visual Studio hangs and crashes. The fixed add-in version is available. (related issue(英語) ). The issue is fixed in TeamCity 6.0.1.

エージェントの TFS チェックアウト
エージェントの TFS チェックアウトは、エラーの処理を拒否する場合があります。パッチが利用可能です。コメント(英語)を参照してください。関連する問題(英語)。この問題は TeamCity 6.0.1 で修正されています。

優先度クラス変更エラー
優先度クラスの優先度番号を変更しているときに、ブラウザーエラーが発生する場合があります。パッチは関連する号(英語)で入手できます。この問題は TeamCity 6.0.1 で修正されています。

IntelliJ IDEA の互換性
IntelliJ IDEA 6 および 7 は、IntelliJ IDEA の TeamCity プラグインでサポートされなくなりました。

また、IntelliJ IDEA X(または他の JetBrains IDE)にアップグレードする予定がある場合は、この既知の問題を確認してください。

ビルド失敗通知
TeamCity 6.0 は、ビルドスクリプトの実行中に発生したビルドエラーと、ビルドの準備中に発生したビルドエラーを区別します。後者の場合に発生するエラーは「開始に失敗しました」エラーと呼ばれ、デフォルトでは Web UI から非表示になっています(ビルド構成ページのキャンセルしてビルドの開始に失敗したオプションを参照)。

TeamCity 6.0 以降、「起動に失敗しました」ビルドに適用される「起動に失敗しました」という通知規則が別にあります。残りのビルド失敗通知はすべて、ビルドスクリプト関連の失敗に関連しています。

アップグレード時に、" ビルドに失敗しました " という通知が表示されているすべてのユーザーは、古い動作を維持するために " ビルドに失敗しました " オプションを自動的に取得します。

プロパティの変更
teamcity.build.workingDir プロパティは、非ランナー設定で使用されなくなりました。下位互換性のため、このプロパティは非ランナー設定でサポートされ、最初に定義されたビルドステップの作業ディレクトリに解決されます。

Swabra と Build Queue Priorities プラグインがバンドルされています
以前にプラグインをインストールしたことがある場合は、アップグレードされた TeamCity バージョンを開始する前に、プラグインを削除してください(通常は .BuildServer/plugins の形式です)。

Maven ランナー
1.5 より古い Java は、Maven ランナーのエージェント部分でサポートされなくなりました。Maven ランナー設定で 1.6+ JVM を指定していることを確認するか、JAVA_HOME がそのような JVM を指していることを確認してください。

NUnit と MSTest のテスト
TeamCity UI(sln および MSBuild ランナー)で構成された NUnit または MSTest テストがある場合、設定はランナーから抽出され、対応するタイプの新しいランナーに変換されます。

テスト起動の実装が変更され、これが相対パスの使用に影響することに注意してください。TeamCity 6.0 では、作業ディレクトリとすべての UI 指定のワイルドカードはビルドの checkout ディレクトリに基づいて解決されますが、以前は .sln ファイルを含むディレクトリに基づいていました。簡単な設定は TeamCity のアップグレード時に変換されますが、ランナーに適切な設定が含まれていることを確認する必要があるかもしれません。

ビルド構成プロパティでの "%" エスケープ
今回、ビルド構成設定で定義された値の 2 つのパーセント記号(%%)は、1 つのパーセント記号のエスケープとして扱われます。以前のバージョンと同様に機能を維持するために、既存の設定はアップグレード時に変換されます。ただし、予期しない「%」記号関連の問題がないか、設定を確認する必要がある場合があります。

. フレームワークプロパティが設定パラメーターとしてレポートされる
以前の TeamCity バージョンでは、インストールされた .Net フレームワーク、Visual Studio、および Mono がビルドエージェントのシステムプロパティとして報告されていました。
これにより、ビルドスクリプトでプロパティを使用できるようになりました。ビルドスクリプトにプッシュされる TeamCity 固有のプロパティの数を減らすために、値は構成パラメーターを介して(つまり、「system。」プレフィックスなしで)報告されるようになり、デフォルトではビルドスクリプトで使用できなくなりました。これらは、「システム」なしで、以前の名前による % 参照を介してビルド構成設定で引き続き使用されます。プレフィックス。

Ipr ランナーは IntelliJ IDEA プロジェクトランナーのために廃止予定です
IntelliJ IDEA プロジェクトのランナーは完全に書き直されます。「IntelliJ IDEA プロジェクト」ランナーという名前ではありません。以前に利用可能だった Ipr ランナーも保持されますが、非推奨としてマークされており、TeamCity の今後のメジャーリリースの 1 つで削除される予定です。既存のビルド構成を新しいランナーに移行することを強くお勧めします。
新しいランナーはテストを実行するために異なるアプローチを使用することに注意してください。IntelliJ IDEA で作成された共有実行構成を用意し、ランナー設定でそれを参照する必要があります。

インスペクションおよび重複データのクリーンアップ
6.0 以降のインスペクションおよびビルドの重複レポートは、ビルドが以前のようにクリーンアップされたときではなく、ビルドが履歴からクリーンアップされたときにクリーンアップされます。

インスペクションおよび Duplicates ランナーには Java 1.6 が必要です
「インスペクション」および「Duplicates(Java)」ランナーには、Java JDK1.6 が必要になりました。Java 1.6 が関連するエージェントにインストールされていることを確認し、ランナーの「JDK ホームパス」設定で指定されていることを確認してください。

XML レポート検証
ビルドランナーの「XML レポート処理」セクションの設定が無効な場合、アップグレード時にビルド構成が「レポートパスを指定する必要があります」というメッセージを報告することがあります。この場合、ランナー設定に移動して構成を修正してください。(関連する問題 (英語))

オープン API の変更
オープン API の変更(英語)を参照してください。devPackage のいくつかの jar が並べ替えられ、一部は runtime サブディレクトリに移動されました。これらの変更に対応するために、プラグインプロジェクトを更新してください。

REST API の変更
いくつかのオブジェクトには、追加の属性とサブ要素があります。解析コードが引き続き機能することを確認してください。

Perforce クリーンチェックアウト
Perforce チェックアウトを使用するすべてのビルドは、サーバーのアップグレード後にクリーンチェックアウトを実行します。これにより、アップグレード後の最初の数時間はサーバーに高い負荷がかかる可能性があり、多くのビルドが「ソースの転送」段階にある間、サーバーが応答しなくなる可能性があることに注意してください。

5.1.2 から 5.1.3 への変更

コマンドラインランナーの実行可能ファイルへのパス
バグ(英語)は完全に修正されました。動作は 5.1 より前のビルドと同じです。

5.1.1 から 5.1.2 への変更

Jabber 通知送信エラーが管理者用 Web UI に再び表示されます(これらのメッセージは 5.1.1 では無効にされていました)。Jabber 通知を使用しない場合は、Jabber 設定サーバー設定ページで Jabber 通知を一時停止してください。

5.1 から 5.1.1 への変更

コマンドラインランナーの実行可能ファイルへのパス
バグ(英語)は部分的に修正されました。動作は、作業ディレクトリが指定されていて、チェックアウトディレクトリと作業ディレクトリの両方にスクリプトがある場合を除いて、5.1 より前のビルドと同じです。作業ディレクトリのスクリプトが使用されます。

ソリューションランナーおよび MSBuild ランナーのスクリプトファイルへのパス
バグ(英語)修正(英語)されました。動作は 5.1 より前のビルドと同じです。

5.0.3 から 5.1 への変更

通知テンプレートの変更
5.1 以降、TeamCity は新しいテンプレートエンジン(Freemarker)を使用して通知メッセージを生成します。新しいデフォルトのテンプレートが提供され、アップグレード前に行われたテンプレートのカスタマイズは無効になります。

このアップグレードの前に通知テンプレートをカスタマイズした場合は、新しい通知テンプレートを確認し、必要に応じて変更してください。古い通知テンプレートは <TeamCity Data Directory>/config/_trash/_notifications ディレクトリにコピーされます。新しいテンプレートと新しい拡張カスタマイズ機能を楽しみましょう。

外部データベースドライバの場所
JDBC ドライバーを WEB-INF/lib ではなく <TeamCity Data Directory>/lib/jdbc ディレクトリに配置できるようになりました。新しい場所を使用することをお勧めします。詳細は外部データベースの設定を参照してください。

PostgresSQL jdbc ドライバは TeamCity インストールパッケージにはもうバンドルされていません。アップグレード時にそれを自分でインストールする必要があります。

データベース接続プロパティ
データベース接続プロパティテンプレートファイルの名前が変更され、<TeamCity Data Directory>/config ディレクトリの database.<database-type>.properties.dist ファイルに配置されます。彼らは .dist ファイルの規則に従います。

database.properties ファイルをデータベース用の新しいテンプレートファイルと比較して確認し、特にカスタマイズしていないオプションを削除することをお勧めします。

デフォルトのメモリオプションの変更
PermGen メモリスペースのデフォルトメモリオプションを変更し、-Xmx JVM オプションを約 1.3G に変更して 32 ビット JVM で実行している場合、「VM の初期化中にエラーが発生しました。オブジェクトヒープ用の十分なスペースを予約していません Java 仮想マシンを作成できませんでした。」

この場合は、次のどちらかを検討してください。

  • 64 ビット JVM に切り替えます。注意事項をご検討ください

  • -XX:MaxPermSize による PermGen メモリの削減 JVM オプション (以前のデフォルトの 120 メートルに)

  • -Xmx JVM オプションによるヒープメモリの削減

Vault Plugin はバンドルされています
このバージョンでは、SourceGear Vault VCS プラグイン(英語)(実験ステータス付き)をバンドルしました。以前にプラグインをインストールした場合は、必ず .BuildServer/plugins からプラグインをアンインストールしてください(プラグインの ZIP を削除するだけです)。

コマンドラインランナーの実行可能ファイルへのパス作業ディレクトリがランナーで指定されている場合、実行可能ファイルへのパスを変更する必要があるバグ(英語)が導入されます。このバグは 5.1.1 で部分的に修正され、5.1.3 で完全に修正されています。

ソリューションランナーおよび MSBuild ランナーのスクリプトファイルへのパス
ランナーで作業ディレクトリが指定されている場合、スクリプトへのパスを変更する必要があるバグ(英語)が導入されます。バグは 5.1.1 で修正されています。

オープン API の変更
オープン API の変更(英語)を参照

5.0.2 から 5.0.3 への変更

特筆すべき変化はありません。

5.0.1 から 5.0.2 への変更

外部変更ビューアー
relativePath 変数は、チェックアウトルールのないファイルの相対パスに置き換えられました。以前の値には、relativeAgentPath を介してアクセスできます。詳細については、TW-10801(英語) を参照してください。

5.0 から 5.0.1 への変更

特筆すべき変化はありません。

4.5.6 から 5.0 への変更

5.0 より前の Enterprise Server ライセンスと Agent ライセンスにはアップグレードが必要です
バージョン 5.0 では、アップグレードポリシーの変更をお知らせしています。5.0 へのアップグレードは無料ではありません。5.0 以降に購入したすべてのライセンス(サーバーおよびエージェント)は、ライセンス購入後 1 年以内にリリースされた TeamCity バージョンで動作します。公式サイトのライセンスとアップグレードセクションで詳細情報を確認してください。

バンドルされたプラグイン
5.0 にバンドルされているスタンドアロンのプラグインを使用した場合は、.BuildServer/plugins ディレクトリからプラグインを削除することを忘れないでください。新しくバンドルされたプラグインは次のとおりです。

  • Mercurial

  • Git (JetBrains)

  • REST API (以前 YouTrack で提供されていた)

その他のプラグイン
TeamCity にバンドルされていないプラグインを使用する場合は、最新バージョンを使用しており、5.0 リリースと互換性があることを確認してください。たとえば、Groovy プラグ(英語)の最新バージョンとその他のプロパティを提供する拡張機能が必要になります。5.0 より前の通知プラグインは、テストごとの割り当てと割り当て責任の通知をサポートしていない場合があります。

古いプロパティ
システムプロパティ「build.number.format」と環境変数「BUILD_NUMBER_FORMAT」が削除されました。ビルドでビルド番号形式を使用する必要がある場合(理由を教えてください)、ビルド番号形式を %system.<property name>% として定義し、ビルド構成で <property name> システムプロパティを定義できます(その後、ビルドに渡されます)。

Oracle データベース
Oracle データベースで TeamCity を使用する場合は、TeamCity Oracle ユーザーに追加特権を追加する必要があります。これを行うには、ユーザー SYS として Oracle にログインして実行します。

grant execute on dbms_lock to <TeamCity_User>;

PostgreSQL データベース
TeamCity 5.0 は PostrgeSQL バージョン 8.3+ をサポートしています。
したがって、PostgreSQL サーバーのバージョンが 8.3 未満の場合は、アップグレードする必要があります。

オープン API の変更 オープン API の変更(英語)を参照してください

4.5.2 から 4.5.6 への変更

特筆すべき変化はありません。

4.5.1 から 4.5.2 への変更

これは 4.5.2 リリースの Rake ランナーに関する重大な問題です。詳細と修正パッチは TW-8485(英語) を参照してください。

4.5.0 から 4.5.1 への変更

特筆すべき変化はありません。

4.0.2 から 4.5 への変更

デフォルトのユーザロール
新しいユーザーのデフォルトとして割り当てられたロールは「すべてのユーザー」グループに移動され、TeamCity にすでに登録されているすべてのユーザーに効果的に付与されます。

サーバーの再起動中にビルドを実行する
サーバーのアップグレード中に実行中のビルドがないことを確認してください。サーバーの再起動中に実行されるビルドがあり、これらのビルドにテストがある場合、ビルドはキャンセルされ、ビルドキュー(TW-7476(英語))に再度追加されます。

LDAP 設定の名前変更
LDAP 統合が構成されている場合、新しいサーバーの最初の起動時にいくつかの設定が自動的に変換されます。名前が変更された設定は次のとおりです。

  • formatDNteamcity.auth.formatDN に名前が変更されます

  • loginFilterteamcity.auth.loginFilter に名前が変更されます

4.0.1 から 4.0.2 への変更

最初のクリーンアップ時間の増加
更新後の最初のサーバーのクリーンアップには、かなり長い時間がかかる場合があります。さらにクリーンアップを行うと、通常の時間に戻るはずです。この最初のクリーンアップ中に、削除されたビルド構成に関連するデータがクリーンアップされます。TeamCity バージョン 4.0 および 4.0.1 のバグのため、以前はクリーンアップされていませんでした。

4.0 から 4.0.1 への変更

「importData」サービスメッセージ引数 ID 引数が type に、ファイルpath に名前変更されました。この変更には下位互換性があります。新しい構文の例については、サービスメッセージの使用セクションを参照してください。

3.1.2 から 4.0 への変更

初期起動時間
TeamCity の新しいバージョンの最初の起動時に、データベース構造がアップグレードされます。このプロセスにより、サーバーの起動時間が長くなる可能性があります。最初の起動には、通常の起動より最大 20 分かかります。この時間は、ビルド履歴のサイズ、ビルドの平均テスト数、サーバーハードウェアに依存します。

アップグレード後にユーザーの再ログインが強制される
アップグレードすると、すべてのユーザーは自動的にログオフされ、ブラウザーで TeamCity Web UI に再ログインする必要があります。アップグレード以降の最初のログイン後、自分を記憶機能は通常どおり機能します。

以前の IntelliJ IDEA バージョンのサポート
このリリースの IntelliJ IDEA プラグインは、IntelliJ IDEA 6.x バージョンと互換性がありません。サポートされている IDEA バージョンは 7.0.3 および 8.0 です。

ビルドで VCS のリビジョンを使う
build.vcs.number.N システムプロパティは build.vcs.number.<escaped VCS root name> プロパティ(またはルートが 1 つしかない場合は build.vcs.number のみ)に置き換えられます。ビルドスクリプトでプロパティを使用した場合は、手動で使用箇所を更新するか、互換モードをオンにする必要があります。ビルド構成設定のプロパティへの参照は自動的に更新されます。対応する環境変数も影響を受けています。さらに読み込む

テストスイート
TeamCity がテストスイートの処理を開始したため、スイート名が定義されたテストは新しいテストとして扱われます。(これらのテストではテスト履歴を最初から始めることができます。)

アーティファクト依存パターン
アーティファクトの依存関係パターンが Ant のようなワイルドカード(英語)をサポートするようになりました。
ディレクトリ名と一致するように "" パターンに依存している場合は、単一の "*" ではなく "/" を使用するようにパターンを調整してください。
"" パターンを使用して拡張子のないファイルのみをダウンロードした場合は、"." を使用するようにパターンを更新してください。

Ivy を使用したアーティファクトのダウンロード
Ivy タスクを使用してビルドスクリプト(Ant build.xml など)からアーティファクトをダウンロードした場合は、ivyconf.xml ファイルを変更し、そこから「統合」以外のすべてのステータスを削除する必要があります。参照として次のページから ivyconf.xml ファイルを取得できます: http://www.jetbrains.net/confluence/display/TCD4/Configuring+Dependencies(英語)

ブラウザーキャッシュ (IE)
Internet Explorer に更新されたアイコン(つまり、実行ボタン)を使用させるには、ページの再読み込み(Ctrl + Shift + R)を強制するか、「インターネット一時ファイル」を削除する必要があります。

3.1.1 から 3.1.2 への変更

特筆すべき変化はありません。

3.1 から 3.1.1 への変更

特筆すべき変化はありません。

3.0.1 から 3.1 への変更

ゲストユーザーとエージェントの詳細

バージョン 3.1 からは、Guest ユーザーはエージェントの詳細ページにアクセスできなくなりました。これは、エージェントの環境に関する機密性の高い情報の公開を減らすために行われました。Enterprise Edition では、Guest ユーザーのロールをユーザーおよびグループページで編集して、必要なレベルの権限を付与できます。

StarTeam サポート

使用中の作業フォルダー

バージョン 3.1 以降の StarTeam リポジトリからファイルをチェックアウトする TeamCity は、以前のバージョンのようにフォルダー名だけではなく、作業フォルダー名に基づいてディレクトリ構造を構築します。そのため、バージョン 3.0 で TeamCity が StarTeam フォルダーを操作する方法に満足している場合は、作業フォルダーの名前が対応するフォルダー名と同じであることを確認してください(デフォルトはそうです)。

また、StarTeam では作業フォルダーとして絶対パスを使用できますが、TeamCity は相対パスのみをサポートし、絶対パスの存在を検出しません。注意して設定を確認してください。

StarTeam URL パーサ修正

バージョン 3.0 では、ユーザーは間違った URL スキームに従っている必要があります。これは starteam:// server:49201 / project / view / rootFolder / subfolder / ... のようなもため、ユーザーがデフォルト以外のビューを参照しようとしたときに機能しませんでした。バージョン 3.1 では、ネイティブ StarTeam URL パーサーが使用されます。これは、URL でルートフォルダーを指定する必要がないことを意味し、前の例は starteam:// server:49201 / project / view / subfolder / ... のようになります。

3.0 から 3.0.1 への変更

Linux エージェントのアップグレード

  • Linux でのエージェントのアップグレードに問題があるため、エージェントのアップグレード後もエージェントの補助ランチャープロセスが実行されたままになっている可能性があります。3.0.1 以降のバージョンではこの問題は修正されています。自動エージェントアップグレードの後、古い実行中のプロセスを取り除くには、( agent.sh kill コマンドで)エージェントを停止し、実行中の java jetbrains.buildServer.agent.Launcher プロセスをすべて終了してからエージェントを再起動してください。

2.x から 3.0 への変更

互換性のない変更

TeamCity 3.0 では、TeamCity 2.x と互換性のないいくつかの変更が導入されています。

  • build.working.dir システムプロパティは teamcity.build.checkoutDir に名前変更されます。このプロパティを使用してスクリプトを作成する場合は、スクリプトを更新してください。

  • runAll.bat スクリプトが必要なパラメーターを受け入れるようになりました: サーバーとエージェントを開始するには start、サーバーとエージェントを停止するには stop。

  • Windows で、agent.bat スクリプトは必須パラメーターを受け入れるようになりました: エージェントを開始して開始、エージェントを停止して停止。この場合、エージェントはアイドルになった後にのみ停止することに注意してください(ビルドは実行されません)。エージェントを即座に強制停止するには、Windows と Linux の両方で使用できる agent.bat stop force コマンド(agent.sh stop force )を使用します。Linux では、agent.sh stop kill コマンドを使用して、agent.sh stop force に応答しないエージェントを停止することもできます。

作業ディレクトリを構築する

TeamCity 3.0 はプロジェクトごとではなく、ビルド設定ごとに VCS ルートを設定する機能を導入したため、エージェント上でビルド設定ソースがチェックアウトされるデフォルトディレクトリに名前が生成されます。ビルド構成で使用されているディレクトリを知る必要がある場合は、<agent home>/work/directory.map ファイルを参照してください。このファイルには、ビルド構成とそれらのディレクトリが使用されています。ビルドチェックアウトディレクトリも参照してください。

TeamCity 1.x/2.x/3.x Professional から 3.x Enterprise にアップグレードする際のユーザーロール

初めて TeamCity 1.x/2.x/3.x Professional から 3.x Enterprise にアップグレードする場合、TeamCity のアカウントにはデフォルトで次のロールが割り当てられます。

  • 管理者はシステム管理者になります

  • ユーザーはすべてのプロジェクトのプロジェクト開発者になります

  • ゲストアカウントはすべてのプロジェクトを表示できます

  • デフォルトのユーザーロールは、すべてのプロジェクトでプロジェクト開発者に設定されています

1.x から 2.0 への変更

データベース設定移動
データベース設定を <TeamCity installation folder>/ROOT/WEB-INF/buildServerSpring.xml ファイルから TeamCity 構成データディレクトリ(<TeamCity Data Directory>/config )にある database.properties ファイルに移動します。

.NET インスペクションおよび継承された複製

teamcity.TruncateIgnoreReasonConverter.copyReasons :

Error collecting changes for VCS repository ... Failed to collect TFS changes - From version x is greater then current version y

以前のバージョンで導入された一時ツールフォルダー(英語)バグが修正(英語)されました。

関連ページ:

IntelliJ プラットフォームプラグイン

TeamCity プラグインは、JetBrains IntelliJ IDEA、RubyMine、PyCharm、PhpStorm / WebStorm、AppCode、Rider などの IntelliJ プラットフォームベースの IDE に TeamCity 統合を提供します。リモートの実行 / 事前テスト済みのコミット機能は、JetBrains によって IDE にバンドルされている VCS 統合でのみサポートされます。サポートされているバージョンのリストについては、JetBrains マ...

Kotlin DSL

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

Jira クラウド統合

Jira クラウド統合ビルド機能を使用すると、ビルドステータスを Jira クラウドにリアルタイムで直接レポートできます。Jira ソフトウェアクラウド REST API を使用し、Jira との通常の統合と比較して追加の認証パラメーターが必要です。これは、TeamCity インターフェースのみに影響します。この機能をビルド構成に追加する前に、親プロジェクトの設定で Jira への課題追跡接続を作成する必要があります。Jira クラウド統合設定 :この機能を設定するには、すべての親プロジェクトで利用...

MS SQL Server による TeamCity の設定

前提条件:MS SQL サーバー、MS SQL Server Management Studio、TeamCity サーバーをインストール、TeamCity で使用される MS SQL サーバーの構成:SQL サーバーの TCP / IP プロトコルを有効にする SQL Server 構成マネージャーを開き、以下を実行します。SQL Server ネットワーク構成を展開し、MSSQL のプロトコルをクリックします。右側のウィンドウで、TCP / IP を右クリックし、有効をクリックして、はいを選...

セカンダリノードの設定

メインの TeamCity サーバーに加えて、データディレクトリと外部データベースをメインサーバーと共有するセカンダリサーバー(ノード)を起動できます。詳細については、マルチノード設定を参照してください。このページでは、セカンダリノードの構成方法について説明します。TeamCity 2019.2 以降、ビルドノードの実行は 2 次ノードのために廃止されることに注意してください。詳細はマルチノード設定を参照してください。セカンダリノードのインストール:セカンダリノードをインストールするには、セカ...

マルチノード設定

TeamCity では、メインインスタンスに加えて、1 つ以上のセカンダリサーバーインスタンス(ノード)を構成および起動できます。メインノードとセカンダリノードは同じライセンスで動作し、TeamCity データディレクトリとデータベースを共有します。マルチノードセットアップを使用すると、次のことができます。ほとんどの操作でダウンタイムがゼロになる高可用性 TeamCity インストールをセットアップします。セカンダリノードは、メインサーバーのダウンタイム中(たとえば、マイナーアップグレード中)は...