TeamCity 2019.1ヘルプ

アップグレードノート

2019.1.3から2019.1.4への変更

  • The bundled Java was updated to OpenJDK 8u222 (except for the Docker Windows TeamCity images).

2019.1.2から2019.1.3への変更

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

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

2019.1.1から2019.1.2への変更

既知の問題

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

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 ディレクトリーの場所を介してエージェントツールを参照する場合、そのような参照はビルド構成で <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は、コンテンツセキュリティポリシー(英語) 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にアップグレードされました。

  • 外部データベース用に自動的に提供される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イメージとプロセス分離を備えたWindows Server2019を使用する場合、ビルドエージェントが起動に失敗する場合があります。(既知の問題で詳細を参照)。この課題を回避するには、「Authenticated Users」グループに「フルコントロール」アクセスを許可します。

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を使用

  • TeamCity 2018.2 OpenJDKはWindowsの.exe TeamCityディストリビューションに含まれているため(2018.2より前のバージョン)Oracle JavaはTeamCity Windowsディストリビューションにバンドルされていました。

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への変更

既知の問題

  • サーバーが2018.1.4にアップグレードしている間に実行されているビルドは、ビルドの失敗を正しく報告せずに、ビルドログとステータスを切り捨てることができます。ビルドログは、「__ tc_longResponseMarker」テキスト( 詳細(英語) )で警告を受け取ります。このバージョンにアップグレードするとき、実行中のビルドがなくなるまで待つことをお勧めします。

その他

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への変更

既知の問題

tcWebHooks(英語)サードパーティTeamCityプラグインを使用している場合は、アップグレードする前に最新バージョンに更新します( 詳細(英語) )。

同様の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には、Docker、Hubで公開されている「最新」およびバージョン番号のタグが付いたマルチプラットフォームのdockerイメージがあります。"jetbrains / teamcity-server"、"jetbrains / 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プロジェクトランナーは、最小バージョンとして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へのパスを指定するフィールドは、エージェント側のチェックアウトのために、エージェント側でのみ機能します。

サーバーの場合、p4バイナリはTeamCityサーバーのPATHに存在する必要があります。(または teamcity.perforce.customP4Path 内部プロパティーで指定できます )。 teamcity.perforce.p4PathOnServerWhitelist 内部プロパティーを使用して、許可されるp4パスのセミコロン区切りリストを指定できます。このリストからのパスは、サーバー側のVCS Root p4パスパラメータで設定できます(古い動作を復元するため)。

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.version に更新され、2017.2.1に更新されます。jdk8で利用可能な追加機能(たとえば、regexpsの名前付きグループ)へのアクセスを提供するために、kotlin-stdlib への依存は kotlin-stdlib-jdk8 への依存と置き換えられます。非推奨の kotlin-runtime への依存性と kotlin-compiler-embeddable への冗長な依存性は削除されます。

今TeamCityは teamcity.dsl.versionkotlin.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プラグイン

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

アップグレード中、既存の.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" サブ要素が追加されました。

build entityブール値の "running"属性を公開せず、代わりに "running"という値を持つテキストの "state"属性を使用します。

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は共通の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. EZ最適化は、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の変更を収集できませんでした - Fromバージョンは現在のバージョンよりも大きいです

TFSバージョン管理を使用し、「VCSリポジトリの変更の収集エラー... TFS変更の収集に失敗しました-バージョンxが現在のバージョンyよりも大きい」エラーが表示された場合、影響を受けるビルド構成に表示されるように新しい変更をコミットする、更新されたプラグイン(英語)をインストールします (関連する課題(英語) )。

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

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

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

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

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

詳細および修正を伴うプラグインについては、https://youtrack.jetbrains.com/issue/TW-46489(英語)要求を参照してください。

.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アドインはVisual StudioのRESHARPERメニューから利用可能になります。

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

IntelliJ IDEAの互換性

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

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

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

Perforce

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

Subversion

TeamCity 10から開始して、TeamCityは、デフォルトでは、信頼されていないサーバーSSL証明書を使用したhttps://プロトコルによってアクセスされるSVNサーバーへの接続を受け入れません。こうした証明書を使用してアクセスを有効にするには、サーバーのJVMのキーチェーンに証明書をインポート、またはVCSルートオプション「信頼できないSSL証明書を受け入れる」(10.0に非信頼できるSSL証明書を有効にします)(有効にする必要があります。いずれかの課題(英語)を )。

同梱ツールの更新

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

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

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

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

GitHub 課題トラッカー

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

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)(副)
projectbuildType が指定された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)
返された結果のソートは、以前のバージョンと比較して一部のクエリでは変更されています。ex:"../app/rest/testOccurrences?locator=build:(xxx) "リクエストはビルドで実行された順番でテストを返すようになりました。
以前は、テスト出現箇所は新しいステータスでソートされ、次に名前でソートされていました。問題発生は問題IDでソートされます。
また、テスト/問題関連ロケーターの build ディメンションは、複数のビルドをサポートするようになりました。そのため、"build"ディメンションを介したいくつかのビルドと一致した要求では、すべてのビルドが処理されます。以前は最初に一致したビルドだけが処理されます。

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

ビルドタイプとテンプレート
settings ノードには、サポートされているすべての設定が含まれていました。現在は、ビルド構成またはテンプレートで定義されているものだけが存在します。 .../app/rest/buldTypes/XXX/settings/* 要求にも同じことが当てはまります。デフォルトから変更された値のみが存在します。

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

9.1.6から9.1.7への変更

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

9.1.5から9.1.6への変更

既知の問題

バンドルされたdotCoverには、Windows XPおよびVistaで実行される既知の課題(英語)があります。提供されている修正プログラム(英語)または回避策(英語)を使用できます。この課題は、次の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ランナーの「アセンブリごとにプロセスを実行する」オプションは、NUnit 3設定から削除されました。対応するフィールドで必要なコマンドラインオプション(英語)を使用して、目的の動作を設定します。

同梱ツールの更新

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

Maven 3.2.xのバンドル版は3.2.5に更新されました。

パフォーマンスモニター

Note on permissions: to monitor performance of a build agent run as a Windows service, make sure the user starting the agent is member of the Performance Monitor Users group.

9.1.4から9.1.5への変更

既知の問題

There is a known issue(英語) in the bundled dotCover run on Windows XP and Vista. You can use the hotfix(英語) or the workaround(英語) provided. The issue will be fixed in the next dotCover release.

製品のアイコン

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:Operationが不安定になる可能性がある」という例外を伴うビルドの失敗を引き起こす可能性がある既知の課題(英語)があります。この課題は、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イメージは、2つのライセンスを消費するEC2-i-abcdefghおよびEC2-i-abcdefgh-1という名前で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ルートは、「p4 login」操作を実行しなくなります。
つまり、パスワード認証が無効になっている場合は、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テストランナーステップに変換されますが、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、その他build locator

ロケータ: 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用の実験的サポートが追加されました。

課題トラッカーの統合

APIの変更により、サードパーティの課題追跡システム統合プラグインはTeamCityバージョン9.1と互換性がない場合があります。古いプラグインは機能せず、teamcity-server.log ログに「java.lang.NoSuchMethodError:jetbrains.buildServer.issueTracker.AbstractIssueProviderFactory。<init>(Ljetbrains / buildServer / issueTracker / IssueFetcher; Ljava / lang / 文字列;)V」エラーが報告されます(詳細課題(英語)の詳細)。このようなエラーが発生した場合は、プラグインの作成者(英語)に連絡してください。影響を受けるプラグインの作成者である場合は、オープン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 ビルドリクエストは、異なる <tags count="1"><tag name="TAG"/></tags><tags><tag>TAG</tag></tags>ではなく)を返すようになりました。
同じことが /app/rest/buildTypes/<buildTypeLocator>/<buildTypeLocator>/buildTags 要求にも当てはまります。
構造の同じ変更は、ビルドのエンティティのネストされた「タグ」要素にも適用されます。

タグを作成するには、プレーンテキストのタグ名を app/rest/builds/<buildLocator>/tags のURLに投稿する古い方法があります。
POSTまたはPUTのXMLまたは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つ重要なことは、データのコピーによって生のデータベースストレージのサイズが増加することです。
これがあなたの場合の課題であるなら(たとえばそれが設定されたデータベースサイズ制限を持つMicrosoft SQL Serverデータベースであるかもしれない)、データベースサイズ制限がアップグレード前の現在のサイズの2倍であることを確認することが推奨されます。VCSの変更移行プロセスが完了した後、データベース固有の手順を実行して実際に格納されているデータと一致するようにストレージを縮小することが可能です。

VCSルート関連の変更

GitおよびMercurial VCSルートは、新しいVCSルート用にサーバー上のカスタムクローンパスを指定する機能を提供しなくなりました: この機能が必要な場合は、gitとmercurialについて、それぞれ true に次の内部プロパティーを設定してください: teamcity.git.showCustomClonePath , teamcity.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で壊れています。修正プログラムが利用可能です。課題のコメント(英語)の指示に従ってください。

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

「Executable with parameters」オプションを使用するコマンドラインランナーは、以前のTeamCityバージョンとは少し異なる方法で引用符( ")とパーセント記号(%)を処理できます( 課題(英語)の詳細を参照)。以前の(8.0)動作に切り替えるにはビルド構成またはプロジェクトでcommand.line.run.as.script = false構成パラメーターを指定できますが、この課題は8.1.1で修正されています。
推奨されるアプローチは、コマンドラインランナーで「パラメータで実行可能」ではなく「カスタムスクリプト」オプションに切り替えることです。

メモリー設定

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

アクションメニュー

一部のアクションは、ページの右上の実行ボタンの近くにあるアクションボタンに移動しました。
ビルドの変更タブのこのビルドソースにラベルを付ける、
ビルド構成設定管理ページの「一時停止」、「コピー」、「移動」、「削除」、「テンプレートに関連付け」、「テンプレートを抽出」、「メタランナーを抽出」、
プロジェクト設定管理ページの「コピー」、「移動」、「削除」、「アーカイブ」、「一括編集ID」。

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

アクション "Create Maven build configuration"は使用できなくなりました。その機能のほとんどは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」のままです。これがREST APIの使用に不便である場合は、対応する課題(英語)にコメントしてください。

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

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

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

リクエスト/ app / rest / buildTypes / XXX / パラメーター / YYYと/ app / rest / projects / XXX / パラメーター / 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と等しくなるように設定され、後で管理UIからIDを再生成または一括編集IDアクションを介して変更できます。

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

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

< 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 Explorer2012からTeam Explorer2010(両方がインストールされている場合)を優先するようになりました

YouTrackとの互換性

JetBrains YouTrackを使用し、そのTeamCity統合機能を使用する場合、TeamCity 8.0と互換性があるのはYouTrackバージョン4.2.4以降のみであることに注意してください。
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、cancelled: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"プロパティーでもサポートされていますが、推奨されていません。"source_buildTypeId"プロパティーを含めるために true に設定できる内部プロパティー "rest.compatibility.includeSourceBuildTypeInDependencyProperties"があります。

バージョン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プラグイン(英語)を使用した場合は、バンドルされているため、必ず削除してください: アップグレード手順(英語)を参照してください

バンドルメイヴン

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

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

7.1から7.1.1への変更

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

7.0.xから7.1への変更

Windowsサービス構成
バージョン7.1以降、TeamCityは、以前のバージョンのデフォルトのTomcat 1とは異なり、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ドメインと通信するために別のライブラリー(Waffle)を使用するようになりました。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の最初の起動時にメッセージ。

ユーザーのデフォルトスキーマを変更するには、' alter user(英語) ' 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でした)で実行する必要があります。Agentの.exeディストリビューションはすでに適切なJavaにバンドルされています。.zipエージェントディストリビューションを使用した場合、またはTeamCityバージョン5.0以前でTeamCityエージェントをインストールした場合は、手動の手順が必要になることがあります。TeamCity 6.5.xを実行している場合は、既存のTeamCityサーバーのエージェントページを確認してください。接続されているエージェントのいずれかが1.6未満のJDKを実行している場合、ページに黄色の警告が表示されます。

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

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

REST APIの変更

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

  • 一部のリソースの単一要素配列の非配列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.3から6.5.4への変更

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

6.5.2から6.5.3への変更

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

6.5.1から6.5.2への変更

メイヴンランナー
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"、変更には "personal" )。解析コードがまだ機能することを確認してください。

デフォルト以外のチェックアウトディレクトリーのクリーニング
以前のリリースでは、絶対パスを使用してビルドチェックアウトディレクトリーを明示的に指定していた場合、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の課題により、自動アップグレードは機能しません。

メイヴンランナー

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

  • そうでなければテストが報告されなかったためMavenリリースのために確実にXMLレポーティングを手動でセットアップしなければならなかった人はTeamCity 6.0.xで造ります。今それを忘れることができます。TeamCity 6.5の確実性テストはリリースごとに実行されるため、準備またはリリース:実行ゴールは自動的に検出されます。そのため、二重報告を避けるためにビルド設定で確実に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
Perforceが有効な場合、TeamCity 6.0 VSアドインに重大なバグがあります。これにより、Visual Studioがハングしてクラッシュする可能性があります。固定アドインバージョンが利用可能です。(関連する課題(英語) )。この課題は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形式)。

メイヴンランナー
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つのパーセント記号(%%)は、単一のパーセント記号のエスケープとして扱われます。以前のバージョンと同様に機能を維持するために、既存の設定はアップグレード時に変換されます。ただし、予期しない "%"サイン関連の課題については設定を確認する必要があります。

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

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

インスペクションと重複データのクリーンアップ
6.0からは、インスペクションとDuplicatesのビルドレポートは、ビルドの履歴が削除されたときにクリーンアップされ、ビルドの成果物が以前のようにクリーンアップされたときにクリーンアップされません。

インスペクションおよびDuplicatesランナーにはJava 1.6が必要です
「インスペクション」および「Duplicates(Java)」ランナーには、Java JDK 1.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で実行している場合、サーバーは次のようなメッセージで起動しない可能性があります。Error occurred during initialization of VM Could not reserve enough space for object heap Could not create the Java virtual machine.

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

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

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

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

Vault プラグインはバンドルされています
このバージョンでは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プラグ(英語)およびその他のプロパティー提供拡張機能が必要になります。Pre-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統合が構成されている場合は、新しいサーバーの最初の始動時にいくつかの設定が自動的に変換されます。名前が変更された設定は次のとおりです。

  • formatDN - teamcity.auth.formatDNに改名されます

  • loginFilter - teamcity.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 エディションでは、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 スクリプトは必須のパラメータを受け入れるようになりました。サーバーとエージェントの起動を開始し、サーバーとエージェントの停止を停止します。

  • エージェントを停止するために停止し、エージェントを起動するために開始 :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のアカウントにはデフォルトで次のロールが割り当てられます。

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

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

  • ゲストアカウントはすべてのプロジェクトを閲覧することができます

  • すべてのプロジェクトでデフォルト・ユーザーロールがProject Developerに設定されている

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

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


関連事項:

管理者ガイド : ライセンスポリシー