TeamCity 2020.1ヘルプ

アップグレードノート

2019.2.xから2020.1への変更

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

  • Java 11 has been bundled with the TeamCity server Windows installer and server Docker images instead of Java 8.

  • TeamCity agents stop supporting Java versions earlier than 8. If any of your agents run on earlier versions of Java, make sure to upgrade their JRE so you can continue running builds on these agents.

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

To better align with current and future Java versions we've introduced a new format of env.JDK_ environment variables.
Starting with 2020.1 the format is as follows: env.JDK_<major>_<minor>[_x64] . For example: env.JDK_1_6 , env.JDK_1_7 , env.JDK_1_8 , env_JDK_11_0_x64 .
This way, if you are using rather old Java 1.4, the proper variable is env.JDK_1_4 , while env.JDK_14_0 will be used for Java 14.0.

For backward compatibility, previous environment variables, such as env.JDK_16 or env.JDK_18 , will be generated too, but these variables will no longer be shown in TeamCity auto-completion popup menus. If you are using these environment variables in your build scripts, we encourage you to migrate to the new format.

See the related issue(英語).

Need for plugin recompilation

Plugins which implement some build runners might need to be recompiled/upgraded.

The corresponding error might look like java.lang.NoSuchMethodError: jetbrains.buildServer.controllers.admin.projects.BuildRunnerBean.getPropertiesBean when a new build step for the corresponding custom build runner is created or updated.

See the related issues about the Checkmarx plugin(英語) and the SonarQube Runner plugin(英語).

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

To comply with recommended security practices, the TeamCity agent Docker images now run under a non-root user.

This change might affect the following use cases:

  • To create/update a custom image based on the standard TeamCity agent image, you might need to switch to the root user first (see the related issue(英語) for details).

  • If you mount a host directory to a container, you might get the " 許諾が拒絶されました " error. To prevent this issue, try any of the following workarounds:
    • Set the UID of the directories' owner to 1000 with the chown command.

    • Send the --user argument with the docker run command to set the same UID for the Docker user as that of the host machine. For example, use docker run -it --user $(id -u) ... .

    • Note that TeamCity automatically creates volumes for writable directories, and there is usually no need to map them explicitly. Consider omitting any explicit references to prevent the permission issues.

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

TeamCity Windows Tray Notifier has been deprecated in favor of the new Browser Notifier extension.

Windows Tray Notifier will continue working with the new version of TeamCity but we recommend you trying the new extension instead. Note that since version 2020.1, the 設定とツール | 通知ルール | Windowsトレイ通知機能 tab in TeamCity has been renamed to ブラウザ通知機能

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

The Kubernetes Support plugin(英語) is now bundled with TeamCity. On upgrade, it will replace the external plugin if it is installed on your TeamCity server. Note that the bundled plugin does not contain the Helm build runner. To continue using this runner in your build configuration, please install the new external plugin(英語).

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

TeamCity improves the security of REST API integration mechanisms by introducing CSRF tokens. This change will not affect the behavior of custom integration scripts unless they rely on Cross-Origin Resource Sharing (CORS) in writing operations and the rest.cors.origins internal property is enabled in TeamCity (it is disabled by default).

Previously, CSRF protection was presented in TeamCity with the verification of Origin/Referer headers of HTTP requests. To improve TeamCity CSRF protection, this method has been disabled in favor of a more secure one – CSRF tokens. Since this release, TeamCity stops supporting the CORS mechanism for POST/PUT/DELETE REST API requests. Cross-origin GET requests' headers are processed as before and still require CORS configuration.

If necessary, you can enforce verification of Origin/Referer headers for writing CORS operations by setting the teamcity.csrf.paranoid=false internal property. Note that this is a transitory and less secure solution: we strongly recommend refactoring your existing requests so they comply with the new security policy and provide a token within a CSRF header or parameter. A CSRF token can be obtained via the GET https://your-server/authenticationTest.html?csrf request and provided via the X-TC-CSRF-Token HTTP header to the write CORS requests.

同梱ツールの更新

  • Bundled IntelliJ IDEA has been updated to version 2020.1.1

  • Bundled Ant has been updated to version 1.9.14

  • Bundled Tomcat has been updated to version 8.5.54

  • Bundled Maven has been updated to version 3.6.3

  • Kotlin , used in TeamCity DSL, has been updated to version 1.3.70

  • JDBC drivers for external databases, suggested on the fresh TeamCity installation, have been updated to the following versions:
    • MySQL - 8.0.20

    • MSSQL - 8.2.2

    • PostgreSQL - 42.2.12

REST APIの変更

Filtering test occurrences by a branch ( .../app/rest/testOccurrences?locator=branch(XXX) request) has been changed. It used to support only branch names with case-sensitive matching. Now, the XXX value supports branch locators (the same as when filtering builds): it is case-insensitive by default and matches the <default> branch display name.

その他の変更点

  • TeamCity has dropped support for Internet Explorer. Please use Microsoft Edge instead.

  • Since this version, the new .NET runner, introduced in TeamCity 2019.2.3, is not compatible with the obsolete external .NET CLI Support(英語) plugin (used in versions 2017.1 and earlier). If you have previously installed this plugin, please uninstall it from your server to be able to use the new .NET runner.

2019.2.3から2019.2.4への変更

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

2019.2.2から2019.2.3への変更

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

The .NET CLI (dotnet) build runner has been refactored and renamed to .NET thus emphasizing that now it supports all .NET-related operations previously implemented in TeamCity as multiple build steps.

All existing .NET CLI (dotnet) steps will continue working as usual under the new .NET name, with no additional tuning required.

We stop providing active support for the MSビルド , Visual Studio (sln) , Visual Studio2003 , and Visual Studioテスト runners. These steps are left for compatibility of existing build configurations with new versions of TeamCity. We recommend switching all your affected build steps to the .NET runner to receive new features and support in our following versions.

See the .NET description for more information about the new .NET step and migration notes.

If you face any problems with migration to the .NET runner or encounter other related issues, do not hesitate to contact us via any convenient feedback channel(英語).

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

The bundled version of Java in Windows installers of TeamCity Server and Agent as well as in the Docker images is updated to Amazon Corretto 8.252.09.1(英語)

2019.2.1から2019.2.2への変更

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

To improve performance on agent checkout, TeamCity caches regular Git repositories on agents. Since this version, it also caches Git submodules.
If your custom scripts or settings depend on the main alternates source for submodules and it causes Git to operate with errors, consider one of the following workarounds:

  • Disable the new mirroring mechanism by setting the build parameter teamcity.internal.git.agent.submodules.useMirrors to false .

  • Modify your custom settings to point at the parent git directory instead of the exact source directory.

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

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

2019.2から2019.2.1への変更

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

2019.1.xから2019.2への変更

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 now can automatically manage the amount of memory used by the git fetch process.
If you have previously used the teamcity.git.fetch.process.max.memory internal property to set the memory amount available for fetching in each VCS root, you can now disable it to delegate the detection of memory consumption to the TeamCity server. To control the limit of available memory, use the teamcity.git.fetch.process.max.memory.limit property.

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

  • バンドルされた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イメージを除く)。

2019.1.2から2019.1.3への変更

既知の問題

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

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

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

2019.1.1から2019.1.2への変更

既知の問題

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

  • If you use the .NET Core ("dotnet") steps on Windows agents, you can get the ".NET SDKが見つかりませんでした" error if you have .NET Core runtime (not SDK) installed on the agent in the location like C:\Program Files (x86)\dotnet . As a workaround, set the env.DOTNET_HOME parameter to the location of .NET Core SDK.
    See the related issue(英語) for details.

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との統合を使用する場合は、ec2:CreateTags(英語)リソースレベルのアクセス許可をAmazonに追加してください。

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

Starting with 2019.1, the behavior of reverse.dep parameters has been changed, and this change can affect your existing builds. In versions prior to 2019.1, when a build chain is triggered, TeamCity only took into account the reverse.dep parameters specified in the top-most build of the chain, i.e. in the build which depends on all other builds. If some intermediate builds of the chain had reverse.dep parameters, they were ignored.
After this fix(英語) this is no longer the case. Now, when a build chain is triggered, all reverse.dep parameters specified in all nodes of the build chain will be processed.

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

エージェントツール (located under the <agent_installation>/tools directory on agents) are now transferred to an agent not on the agent upgrade, but right before the first build that uses the respective tool. You might need to update the build configuration settings so TeamCity knows which tools are required by the builds.
Before starting a build on an agent, TeamCity checks for the references to teamcity.tool.<tool_ID> configuration parameters to collect the set of tools used by the build. If some tool is referenced via this parameter, TeamCity will make sure this tool is present on the agent before the build logic starts executing.
If some of your builds use tools on agent assuming their locations under the <agent installation>/tools directory, such references should be changed to a TeamCity-provided parameter reference. Paths like <agent_installation>/tools/<tool_ID> used in TeamCity settings should be changed to the %teamcity.tool.<tool_ID>% parameter reference. For example, ../tools/maven3.4.5/bin/mvn should be replaced with %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ヘッダー値

Now TeamCity web UI uses more restrictive value for the コンテンツセキュリティポリシー(英語) HTTP header. This provides extra security at the expense of prohibiting usage of the web resources not hosted on the TeamCity server.
If you rely on external resources (for example, in the build report tabs content or by using not yet updated plugins), you can specify new header value in the teamcity.web.header.Content-Security-Policy.protectedValue=<full_header_value> internal property (and teamcity.web.header.Content-Security-Policy.adminUI.protectedValue property for the web pages in Administration area). Plugins can use ContentSecurityPolicyConfig(英語) open API interface to add to the value configured.

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

The dotCover.dcvr hidden artifact is no longer published by default. It is now created in the build temporary folder and removed when the build finishes.
If you use dotCover and rely on this artifact, specify the path to the %system.teamcity.build.tempDir%\..\agentTmp\dotNetCoverageResults\dotCover.dcvr file explicitly in the アーティファクトパス

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

  • 最新の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イメージとプロセス分離を備えた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を使用

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

既知の問題

  • サーバーが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には、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へのパスを指定するフィールドは、エージェント側のチェックアウトのために、エージェント側でのみ機能します。

サーバーの場合、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.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プラグイン

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)を確認できません」と報告することがあります。

詳細および修正を伴うプラグインについては、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アドインは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)
When performing builds scan to find those matched by the locator specified, by default for performance reasons TeamCity will return partial result limited by scanning only 5000 most recent builds. To process a larger portion of the history, check the nextHref attribute returned or set the lookupLimit locator dimension to a larger value.
Previously, until specifically requested the builds from non-default branch as well as canceled, personal and failed to start builds were not returned. Now these filtered out builds are returned by default for running and queued builds queries as well as when filtering by agent or user. Use defaultFIlter:true/false locator dimension to manage the default filtering explicitly.
Also, number:NNN locator now adheres to the same default logic: only "usual" finished builds from default branch are searched by number and several builds can be returned if found.

VCSの根を見つける ( .../app/rest/vcsRoots/... URL )(minor)
A VCS root locator with project and buildType specified used project as the context for finding buildType . This is no longer the case,the buildType locator should be full one to find the build configuration.

構成のアーティファクト依存関係を構築する (entities returned by .../app/rest/buildTypes/... URL)
The artifact-dependencies sub-element of the buildType element now uses textual generated ids instead of numeric ones which depended on the order previously. This also affects requests for artifact dependencies modification.
The agent-requirements sub-element of the buildType element now uses generated ids instead of the parameter name as id. This also affects requests for agent requirements modification.

エージェント要件の編集 ( .../app/rest/buildTypes/.../artifact-requirements/... URL)
Previously, on adding a new agent requirement for the same parameter, the existing one was overridden by the new one; now a new one is added.Previously, on adding a new agent requirement, the parameter name was derived from the id attribute of the agent-requirement node. Since TeamCity 10, the parameter name is derived from the " property-name " property.

テストと問題の発生 ( .../app/rest/testOccurrences , .../app/rest/problemOccurrences URL)
The sorting of the returned results is changed for some of the queries compared to the previous versions. For example, the "../app/rest/testOccurrences?locator=build:(xxx) " request now returns the tests in the order they were run in the build.
Previously, test occurrences were sorted by the new status and then by name. Problem occurrences were sorted by problem id.
Also, the build dimension in the test/problem-related locators now supports multiple builds so for the requests which matched several builds via the " build " dimension, all the builds will be processed; previously only the first matching build was processed.

エンティティー
The property entity used to have its "own" Boolean attribute indicating whether the parameter is redefined in the build configuration as opposed to inherited from a template/project. Now the attribute is renamed to ' inherited ' and its value is inverted.
The vcs-root and vcs-root-instance used to have status and lastChecked attributes. Now VCS root instance has status element (with current node which has status and and timestamp attributes) and VCS root does not have the data as it produced undefined results in case of several VCS root instances.
The test entity id became Sring instead of Long (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に更新されました。

パフォーマンスモニター

権限に関する注意:Windowsサービスとして実行されるビルドエージェントのパフォーマンスを監視するには、エージェントを起動するユーザーがPerformance Monitor Usersグループのメンバーであることを確認してください。

9.1.4から9.1.5への変更

既知の問題

バンドルされたdotCoverには、Windows XPおよびVistaで実行される既知の課題(英語)があります。提供されている修正プログラム(英語)または回避策(英語)を使用できます。この課題は、次の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) name allowed as a Groovy identifier (the property name does not contain dots): customUserProperty
b) name not allowed as a Groovy identifier (the property name contains dots, e.g. 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イメージは、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 VCS Roots with disabled ticket authentication won't run 'p4 login' operation anymore if password authentication is disabled on the Perforce server.
I.e. if password authentication is disabled, "Use ticked-based authentication" option must be enabled on the VCS Root. 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"ロケーターディメンションが指定されるまで、ビルドの開始に失敗したものは含まれません。

Details:
Affected requests: /app/builds/<locator>..., /app/builds?locator=<locator>, /app/buildTypes/<btLocator>/builds and others with 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 / String;)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以降の新しいビルドでも同じです)

タグ関連の変更を構築する
The /app/rest/builds/<buildLocator>/tags build request now returns a different XML: <tags count="1"><tag name="TAG"/></tags> instead of <tags><tag>TAG</tag></tags> .
The same applies to the /app/rest/buildTypes/<buildTypeLocator>/<buildTypeLocator>/buildTags request.
The same change in the structure also applies to the build's entity nested "tags" element.

To create a tag, there is an old way to post a plain-text tag name to the app/rest/builds/<buildLocator>/tags URL.
When sending POST or PUT XML or JSON requests to the URL, the new XML format is to be used ( <tag name="TAG"/></tags> instead of <tag>TAG</tag> ).

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

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

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

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

データベース関連の変更

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

Upon upgrade and entering the normal working status, TeamCity starts a background process to move the entries from the vcs_changes database table to vcs_change table. This process is transparent and you can continue working with the server as usual. It has negligible impact on the server performance and the only affected logic is the projects import feature (it is recommended to be used only with backups taken after the process is completed). The progress of the process can be seen on the Backup section in the server administration, along with "TeamCity is currently optimizing VCS-related data in the database for better backup/restore performance" message.
The other important thing is that the data copying increases the size of the raw database storage.
If this is an issue for your case (e.g. it might be with Microsoft SQL Server database with set database size limit), it is recommended to ensure the database size limit is twice the current size before the upgrade. It is possible to perform database-specific procedures to shrink the storage to match the actually stored data after the VCS changes migration process finishes.

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で壊れています。修正プログラムが利用可能です。課題のコメント(英語)の指示に従ってください。

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

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ビルド構成は使用できません

アクション "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 / 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 のサーバー上のディレクトリ名にも使用されています。

If you used any of the above, please, verify if you are affected by the change.
Learn more about IDs at 識別子

On upgrade, all the projects get automatically generated IDs based on their names.
Build configuration IDs are set to be equal to internal (btNNN) ids and can be later changed from the Administration UI via the IDを再生成 or 一括編集ID actions.

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

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

The format of the project settings storage on the disk under < TeamCity Data Directory >/config has been changed.
If you used any tools to read or update project-config.xml files, you will need to update the tools. It is recommended to use REST API or TeamCity open API (Java) to make changes so that the tools are not hugely affected by the format change.

構成テンプレートの構築

バージョン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との互換性

If you use JetBrains YouTrack and use its TeamCity integration features, please note that only YouTrack version 4.2.4 and later are compatible with TeamCity 8.0.
If you need earlier YouTrack versions to work with TeamCity 8.0, please let us know(英語).

REST API

外部ID There are changes in the API related to the new external ids for project/build types/templates as well as other changes.
The old API compatible with TeamCity 7.1 is still provided under "/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"をロケーターに追加してください。

The "relatedIssues" element of the build entity no longer contains a full list of related issues. It has only the "href" attribute whose value can be used to get the related issues via a separate request.
There is also an internal property "rest.beans.build.inlineRelatedIssues" which can be set to true to return the "relatedIssues" node back for compatibility. See TW-20025(英語) for details. Also, the ".../builds/xxx/related-issues" URL is renamed to ".../builds/xxx/relatedIssues".

The "source_buildTypeId" property is dropped from snapshot and artifact dependency nodes. Instead, the "source-buildType" sub-element is added with a reference to the build type.
Creating dependencies is still supported with the "source_buildTypeId" property, but is deprecated. There is an internal property "rest.compatibility.includeSourceBuildTypeInDependencyProperties" which can be set to true to include the "source_buildTypeId" property back.

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

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

7.1から7.1.1への変更

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

7.0.xから7.1への変更

Windowsサービス構成
Since version 7.1, TeamCity uses its own service wrapping solution for the TeamCity server as opposed to that of default Tomcat one in previous versions.This changes the way TeamCity service is configured (Data Directory and server startup options including memory settings) and makes it unified between service and console startup.
Please refer to the updated section on configuring the server startup properties.

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

Windowsインストーラーと一緒にインストールされた場合のTeamCityデータディレクトリのデフォルトの場所
This is only relevant for fresh TeamCity installations with Windows installer. Existing settings are preserved if you upgrade an existing installation.
Windows installer now uses %ALLUSERSPROFILE%\JetBrains\TeamCity location as default one for TeamCityデータディレクトリ . In TeamCity 7.0 and previous versions that used to be %USERPROFILE%\.BuildServer .

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

Unless you specified specific settings for jCIFS library in ntlm-config.properties file, your installation should not be affected.
If you experience any issues with login into TeamCity with your Windows username/password after upgrade, please provide details to us(英語). In the mean time you can switch to using old jCIFS library. For this, add teamcity.ntlm.use.jcifs=true line into internal properties file.
Please note that jCIFS library approach can be depricated in future versions of TeamCity, so the property specification is not recommended if you can go without it.

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テストランナーでビルドがハングアップしたりメモリエラーが発生することがある
Affected are: .Net test runners (NUnit, MSTest, MSpec) as well as TeamCity NUnit console launcher.
Reproduces when path to test assemblies has several deep paths without wildcards ("*").

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

The issue ( TW-20482(英語) ) is fixed and the fix will be included in the next release.
Patch with a fix is available(英語).

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のサポートは終了しています
From this version support for Sybase as external database is shifted back into "experimental" state.
The reason for this decision is that it does not seem like the database is actively used with TeamCity, and supporting it requires a significant effort from TeamCity team which otherwise can be directed to improving more important areas of the product.
While it should be still possible(英語), we do not recommend using Sybase as an external database and we are not planning to provide support for the Sybase-related issues.
Please consider using one of the other databases supported. If you use Sybase, please migrate to another database before upgrading 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ランナー
Working with MAVEN_OPTS has changed again. Hopefully for the last time within the 6.5.x iteration. (see http://youtrack.jetbrains.net/issue/TW-17393(英語) )
Now TeamCity acts as follows:

  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へのパスが正しいことを確認し、この切り替えを確認することです。自動的に行われます。操作はエージェントごとに行われるため、エージェントごとに個別に作成する必要があります。Java 1.6に切り替えることをお勧めします。ある時点でTeamCityはJava 1.5.と互換性がないため、新しく選択した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テストレポート設定は、ランナー設定から専用のビルド機能に移動されます。

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

責任は「調査」に変更されます
A responsibility assigned for a failing build configuration or a test is now called investigation. This is just a terminology change to make the action more neutral.
If you have any email processing rules for TeamCity investigation assignment activity, please check is they need updating to use new text patterns.

REST APIの変更
いくつかのオブジェクトは追加の属性とサブ要素を持っています(たとえばビルドに関しては "startDate"、変更には "personal" )。解析コードがまだ機能することを確認してください。

デフォルト以外のチェックアウトディレクトリのクリーニング
In previous releases, if you have specified build checkout directory explicitly using absolute path, TeamCity would not clean the content of the directory to free space on the disk.
This is no longer the case.
So if you have absolute path specified for the checkout directory and you need the directory to be present on agent for other build or for the machine environment, please set system.teamcity.build.checkoutDir.expireHours property to "never" and re-run the build. Please take into account that using custom checkout directory is not recommended.

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

空きディスク容量
This release exposes 空きディスク容量 in UI that was earlier only available via setting build configuration properties.
While the old properties still work and take precedence, it is highly recommended to remove them and specify the value via "Disk Space" build feature instead. Future TeamCity versions might stop to consider the properties specified manually.

コマンドラインランナー
「カスタムスクリプト」ランナーパラメータで提供されるスクリプトに、コマンドエコーを無効にする @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レポート処理
Tests from Ant JUnit XML reports can be reported twice (see TW-19058(英語) ), as we no longer automatically ignore TESTS-xxx.xml report.
To workaround this avoid using *.xml mask and specify more concrete rules like TEST-*.xml or alike that will not match report with name starting with "TESTS-"

オープンAPIの変更
Several return types have changes in TeamCity open API, so plugins might need recompilation against new TeamCity version to continue working.
Also, some API was deprecated and will be discontinued in later releases. It is recommended to update plugins not to use deprecated API.
See also オープン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形式)。

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

.フレームワークプロパティが設定パラメータとしてレポートされる
In previous TeamCity versions, installed .Net Frameworks, Visual Studios and Mono were reported as System Properties of the build agents.
This made the properties available in the build script.In order to reduce number of TeamCity-specific properties pushed into the build scripts, the values are now reported via Configuration Parameters (that is, without "system." prefix) and are not available in the build script by default. They still be used in the Build Configuration settings via %-references by their previous names, just without "system." prefix.

IprランナーはIntelliJ IDEAプロジェクトランナーのために廃止予定です
Runner for IntelliJ IDEA projects was completely rewritten. It is not named "IntelliJ IDEA Project" runner. Previously available Ipr runner is also preserved but is marked as deprecated and will be removed in one of the further major releases of TeamCity. It is highly recommended to migrate your existing build configurations to the new runner.
Please note that the new runner uses different approach to run tests: you need to have a shared Run Configuration created in IntelliJ IDEA and reference it in the runner settings.

インスペクションおよび重複データのクリーンアップ
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で実行している場合、「VMの初期化中にエラーが発生しました。オブジェクトヒープ用に十分なスペースを確保できません。Java仮想マシンを作成できませんでした。」

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

  • 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 supports PostrgeSQL version 8.3+.
So if the version of your PostgreSQL server is less than 8.3 then it needs to be upgraded.

オープン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がテストスイートを処理し始めたという事実により、スイート名が定義されたテストは新しいテストとして扱われます (これらのテストではテスト履歴を最初から始めることができます。)

成果物依存パターン
Artifact dependencies patterns now support Antのようなワイルドカード(英語) .
If you relied on "" pattern to match directory names, please adjust your pattern to use "/" instead of single "*" .
If you relied on the "" pattern to download only the files without extension, please update your pattern to use "." for that.

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 inspection and duplicates inherited

teamcity.TruncateIgnoreReasonConverter.copyReasons :

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

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

関連ページ:

REST API

TeamCityは、外部アプリケーションを統合し、TeamCityサーバーとのスクリプト相互作用を作成するためのREST APIを提供します。このページは3つのメインセクションで構成されています。一般情報は、REST API認証の原理、リクエストの構造、サポートされるHTTPメソッドについて説明して...

追加のプラグインをインストールする

プラグインリポジトリでTeamCityプラグインを取得できます。JetBrains プラグインリポジトリからプラグインをインストールする:TeamCity 2018.2以降、プラグインリポジトリからプラグインをインストールできます。管理 | プラグインリストページに移動し、プラグインリポジトリを参照...

MS SQL ServerによるTeamCityの設定

このページで:前提条件、TeamCityで使用されるMS SQLサーバーの構成SQLサーバーのTCP / IPプロトコルを有効にする、新しいデータベースを作成する、TeamCityデータベースユーザーをセットアップするSQLサーバー認証でTeamCityの専用ユーザーを作成する、Windows認証で...

セカンダリノードの設定

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

マルチノード設定

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

テストと設定の問題の表示

プロジェクト概要ページでの問題の表示:プロジェクト概要ページには、ビルド構成で失敗したテストの数やその他の問題も表示されます。問題のあるビルド構成のデータが展開されていない場合、テスト番号のリンクから現在の問題タブに移動します(以下を参照)。ビルド構成データを展開すると、問題の概要が表示されます。ブ...