TeamCity 2020.1ヘルプ

既知の問題

このページには、TeamCityの既知の課題に対する回避策のリストが含まれています。

TeamCityの特定のバージョンに固有の課題を確認するには、それぞれのセクションにアクセスしてください。

JDK 8アップデート242+との非互換性

JDK 8u242 +で実行されている2019.2.1までのTeamCityバージョンは、Git操作またはWindowsドメイン認証操作などで java.lang.NoClassDefFoundError: Could not initialize class XXX エラーを報告できます。

TeamCity 2019.2.2がリリースされるまで、TeamCityサーバーにはJava 8u232バージョンを使用することをお勧めします。

Windowsサービスとして実行されているエージェント

TeamCityビルドエージェントをWindowsサービスとしてインストールすると、ビルドプロセス中にさまざまな "Permission denied"または "Access denied"エラーが表示されることがあります。詳細は以下を参照してください。

セキュリティ関連の課題

サービスで使用されるユーザーアカウントには、ビルドを実行してサービスを管理するための十分なアクセス許可が必要です。SYSTEMアカウントでTeamCityエージェントサービスを実行している場合は、次の手順を実行します。

  1. 必要な権限が付与された通常のユーザーアカウント用の変更 SYSTEM。

  2. サービスを再開してください。

Windowsサービスの制限

Windowsサービスとして、TeamCityエージェントとビルドプロセスはネットワーク共有とマップされたドライブにアクセスできません。

これらの制限を克服するには、コンソールから TeamCityエージェントを実行してください。

自動GUIおよびブラウザテストの課題

これらの課題には、ヘッドレステストの実行エラー、TeamCityエージェントとWindowsデスクトップとの相互作用の課題などが含まれます。

これらを解決/回避するには

  1. コンソールから TeamCityエージェントを実行します。

  2. デスクトップをロックするスクリーンセーバーを起動しないようにビルドエージェントマシンを設定します。

  3. TeamCityエージェントを自動的に開始するように構成します(たとえば、Windows開始時に自動ユーザーログオンを構成し、ユーザーログオン時にTeamCityエージェントの開始を(agent.batを介して)構成します)。

グラフィカルテストの場合、ビルドエージェントをサービスとして開始することはできません。ユーザーの自動ログオン後1分遅れてビルドエージェントの起動を構成することをお勧めします。タスクスケジューラで bin\agent.bat start コマンドを使用し、そこで遅延を構成します。

自動GUIテストの実行とRDPの使用

RDPはセッションのためにマシンのビデオカードからのものをオーバーライドするそれ自身のビデオドライバを使用します。セッションをコンソールにリダイレクトすると、Windowsのグラフィカルドライバがアンロードされます。これは、テストの前にビルド構成に次の手順を追加することで実行できます(以下の例はPowerShell用ですが、他の言語(DOS、Python)も使用できます)。

$sessionInfo=((quser $env:USERNAME | select -Skip 1) -split '\s+') if ($sessionInfo[1] -like "rdp-tcp*") { tscon $sessionInfo[2] /dest:console }

ここで、「quser [current username]」は、コンソールまたはグラフィカルのいずれかで、ユーザーのそのマシンへのすべての接続をリストします。
rdp-tcp#* としてリストされているのは、「tscon [connection id] /dest:console」を使用してコンソールにリダイレクトできるリモートデスクトップ接続です。

.NET Seleniumの課題

TeamCityエージェントがWindowsサービスとして開始され、.NETアプリケーションの自動テストがSelenium WebDriverを使用する場合、ブラウザードライバーの制限が原因でテストが失敗することがあります。解決策として、エージェントを手動で開始することを検討してください。

他のリソースが初期化される前のサービスの早期開始

これを処理するには、サービス設定の自動 (遅れたスタート)オプションの使用を検討するか、サービスの依存関係(英語)を構成します。

詳しい調査手順については、よくある問題のページを参照してください。

java.lang.OutOfMemoryError:新しいネイティブスレッドエラーを作成できません

TeamCityサーバーがSUSE®Linux Enterprise(またはsystemd Daemonを使用)で実行されている場合、java.lang.OutOfMemoryError:新しいネイティブスレッドエラーを作成できませんは、cgroupプロセス番号コントローラー(英語)機能がプロセスの数(英語)とcgroup内のスレッドの量をデフォルトで512に制限するために発生する可能性があります。

制限を大きくすると(TeamCityサーバーの4096など)、課題は解決します。

この外部投稿(英語)も参照してください。

ブラウザキャッシュの消去

一部のユーザーが遭遇した(および他のコンピューターで再現できない)Web UI関連の課題は、コンテンツのキャッシュバージョンに関連しています。このような課題に遭遇した場合は、ブラウザーのキャッシュをクリアして、ブラウザー(英語)がコンテンツのキャッシュバージョンを使用しないようにしてください。

テストでLog4jを使ってロギングする

テストでLog4jロギングを使用していると、場合によってはLog4jの出力がログから失われることがあります。そのような場合は、次の手順に従ってください。

  • Log4j 1.2.12を使用

  • Log4j 1.2.13+の場合、Log4j構成で使用されるコンソールアペンダに "Follow=true" パラメータを追加します。

    <appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender"> <param name="Follow" value="true"/> </appender>

エージェントサービスは、Windows x64でのユーザーログアウトで終了できます。

使用されているバージョンのJavaサービスラッパー(英語)はWindows 64を完全にはサポートしていないため、ユーザーのログアウト時にエージェントランチャープロセスが強制終了されます。エージェント自体は、次回の再起動(サーバーのアップグレードまたはエージェントのプロパティの変更)まで機能します。

失敗したビルドは、Maven 2.0.7で成功したものとして報告できます

これは、このバージョンのMavenの既知のバグです。それ以降のバージョンの使用を検討してください。
それが不可能な場合は、mvn.batの148行目のフラグメントを置き換えることにより、mvn.bat に自分でパッチを適用できます。

:error set ERROR_CODE=1

次のように:

:error if "%OS%"=="Windows_NT" @endlocal set ERROR_CODE=1

矛盾するソフトウェア

競合するソフトウェアの最も一般的な指標は、"Access is denied"、"Permission denied"、または存在し、エージェント/ビルドが実行されているユーザーによって書き込み可能なファイルについてメンションしているjava.io.FileNotFoundExceptionなどのエラーです。また、バックグラウンドで実行されている特定のソフトウェア(アンチウイルスなど)は、ソースのチェックアウト、アーティファクトの公開、またはビルドの実行など、ビルドエージェントの操作を大幅に遅くする可能性があります。

カスペルスキーインターネットセキュリティなどの特定のウイルス対策ソフトウェアは、Javaプロセスのクラッシュや、ファイルにアクセスできないなどのその他の不正動作を引き起こす可能性があります。例: 課題(英語)を参照してください。

ESETアンチウイルスはAnt / IntelliJ IDEAプロジェクトを遅くすることもできます(エージェント上のlocalhostへのTCP接続を遅くする)。

TeamCityサーバーまたはエージェントマシンでウイルス対策を実行し、ディスクアクセスエラーが発生したり、パフォーマンスが低下したりする場合は、課題を調査してJetBrainsに報告する前に、ウイルス対策ソフトウェアを無効にするか完全にアンインストールします。

TeamCityサーバーホーム全体とTeamCityデータディレクトリをバックグラウンドチェックから除外し、既知のメンテナンスウィンドウで定期的なチェックを実行して、サーバーのパフォーマンスに大きな影響を与えないようにすることをお勧めします。TeamCityエージェントでは、バックグラウンドチェックからTeamCityエージェントホームを除外することをお勧めします。

Windowsインデックスサービスに課題がある可能性があるため、さまざまなインデックスサービスを無効にします。詳細については、関連する課題(英語)を参照してください。Windowsシステムの復元機能も無効にする必要がある場合があります。

WinCVS、TortoiseCVS、TortoiseSVN、およびその他のTortoise *製品のようなバックグラウンドインデックス付きのソフトウェアをインストールしないでください。これはサーバーに適用され、エージェント側のチェックアウトを使用する場合はエージェントにも適用されます。

Skypeソフトウェアは、以下のことが知られています。

  • システムのポート80を使用すると、デフォルトのポート80ではTeamCityサーバーを利用できない可能性があります。

  • Internet Explorerに表示されるページのレイアウトが正しくありません。Internet ExplorerのSkypeプラグインは非難することです。(TW-13052(英語)

Subversionの課題

SVN: E175002: 致命的なアラートを受信: bad_record_mac

ビルドサーバーにシステムプロパティ -Dsvnkit.http.sslProtocols=SSLv3,TLS を追加します(TeamCityサーバー起動プロパティの設定を参照)。
エージェントでチェックアウトを使用する場合は、ビルドエージェントでもこのプロパティを追加します。

Subversion関連のJVMクラッシュ

SVN関連のコード(org.tmatesoft.svnパッケージなど)の実行中にJVMがクラッシュした場合は、次のいずれかの方法で無効にすることができます。

  • クラッシュしたプロセスに -Dsvnkit.useJNA=false JVMオプションを渡す (サーバーまたはエージェント)

  • -Dsvnkit.http.methods=Basic,Digest,NTLM JVMオプションを渡すことにより、NTLMサポートの優先順位を下げます。
    使用されているJVMを利用可能な最新(英語)バージョンにアップグレードすることをお勧めします。

NUnit 2.4.6のパフォーマンス

NUnit 2.4.6の課題により、そのパフォーマンスはNUnit 2.4.1より遅くなるかもしれません。追加情報については、当社の課題トラッカーの該当する課題を参照してください。TW-4709(英語)

StarTeamの性能

TeamCityサーバーでStarTeam SDK 9.3の代わりにStarTeam SDK 9.0を使用すると、TeamCityサーバーとStarTeamサーバー間の接続が遅い場合に、VCSのパフォーマンスが大幅に向上します。

WindowsでのPerforce 2009.2パフォーマンス

WindowsでPerforce 2009.2を実行すると、大幅なスローダウンが発生する場合があります。これは、Windowsで実行されているP4サーバーの課題です。Perforceのドキュメントの対応するセクション(英語)を参照してください。

ビルドスケジュールされたトリガーの間違った時間 (タイムゾーンの課題)

プラットフォームで利用可能な最新のJava 8インストール用アップデート(たとえばOpenZDK 8 by Amazon Corretto(英語))を使うようにしてください。

IntelliJ IDEAをアップグレードすると、事前にテストされたアクティブなコミットに影響を与える可能性があります

IntelliJ IDEA X(または他のIntelliJ Xプラットフォーム製品)にアップグレードする前に、アクティブな事前テスト済みコミットがないことを確認してください。そうしないと、アップグレード後にコミットできなくなります。これは、ディレクトリベースのIDEAプロジェクトを使用する場合にのみ関係します(プロジェクトファイルは .idea ディレクトリに格納されています)。

同じサーバー上で実行されている他のJavaアプリケーション

同じホスト名で他のWebアプリケーションが利用可能な場合は、セッションCookieの競合が発生する可能性があります。これは通常、ランダムなユーザーのログアウトやセッションレベルのデータの消失によって見えます。(例:TW-12654(英語))これを解決するために、アプリケーションにアクセスするときに異なるホスト名を使用できます。

データベースが使用中であると主張してサーバーが起動しない

1つのTeamCityサーバーのみが1つのデータベースを処理できます。これはTeamCityサーバーの起動時にチェックされます。

次のいずれかの場合に、起動時の "The Database is in Use"エラーが報告されます。

  • 同じデータベースに接続されている複数のTeamCityサーバーを始動しようとしました

  • 2番目のTeamCityインスタンスが検出された

  • 内部HSQLデータベースが別のアプリケーションによって使用されています

このエラーは、おそらく同じデータベースに接続されている別の実行中のTeamCityインストールがあるという事実によって引き起こされます。データベースのプロパティが正しいこと、および同じデータベースを使用しているTeamCityサーバーが他にないことを確認してください。

TeamCity 8.0以前、すべての設定が正しい場合、TeamCityサーバーまたはデータベースサーバーが誤ってシャットダウンされたときにエラーが発生する可能性があります。解決方法はデータベースの種類によって異なります。

  • MySQL : MySQLサーバーを再起動してからTeamCityを再起動します。

  • PostgreSQLOracleMS SQL:誤ってシャットダウンしたTeamCityから接続を強制終了してから、再度TeamCityを起動します。

  • 内部データベース(HSQL):<TeamCityホーム> \ systemディレクトリから buildserver.lck ファイルを削除してから、TeamCityをもう一度起動します。

TeamCityサーバーからのダウンロードが遅い

TeamCityからアーティファクトをダウンロードするときに速度が遅い場合は、localhostからダウンロードしてサーバーマシンで速度を確認してください。localhostの速度が課題ない場合、TeamCity(Tomcat)設定と組み合わせると、課題はネットワーク構成またはOS /ハードウェア設定にある可能性があります。

<TeamCityホーム> \ conf \ server.xmlファイルがTeamCityディストリビューションに含まれているファイルに対応していることを確認してください(.tar.gzディストリビューションで確認できます)。次の「コネクタ」ノードがある場合(ポート番号は異なる場合があります):

<Connector port="8111" protocol="HTTP/1.1" connectionTimeout="60000" redirectPort="8543" useBodyEncodingForURI="true" />

それをに変更します。

<Connector port="8111" protocol="org.apache.coyote.http11.Http11NioProtocol" connectionTimeout="60000" redirectPort="8543" useBodyEncodingForURI="true" socket.txBufSize="64000" socket.rxBufSize="64000" tcpNoDelay="1" />

TeamCityサーバーを再起動します。

これがダウンロード速度を助けない場合、ケースを調査するために、ケースを調査するために適切なネットワーク関連課題調査スキルを持つ管理者を見つける必要があるかもしれません。

IISリバースプロキシの背後にあるサーバーにアーティファクトを公開できない

この問題は、ビルドサーバーとエージェント間のIISリバースプロキシを含む構成にのみ関係します。ビルドアーティファクトをサーバーに公開しようとしているビルドエージェントが無限ループで見つかることがあります。ビルドログは次のようになります。

[11:15:05]Publishing artifacts [11:15:05][Publishing artifacts] Collecting files to publish: [toZip/** => artifact.zip] [11:15:06][Publishing artifacts] Creating archive artifact.zip (9s) [11:15:06][Creating archive artifact.zip] Creating C:\BuildAgent\temp\buildTmp\ZipPreprocessor2847146024236637664\artifact.zip [11:15:15][Creating archive artifact.zip] Archive was created, file size 32142324 bytes [11:15:15][Publishing artifacts] Sending toZip/** [11:15:25][Publishing artifacts] Sending toZip/** [11:15:39][Publishing artifacts] Sending toZip/** [11:15:48][Publishing artifacts] Sending toZip/** [11:16:01][Publishing artifacts] Sending toZip/** [11:16:16][Publishing artifacts] Sending toZip/**

一方、teamcity-agent.logはIISからの404の応答でいっぱいになります。

[2012-08-01 12:04:55,514] WARN - jetbrains.buildServer.AGENT - <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"/> <title>404 - File or directory not found.</title> <style type="text/css"> <!-- body{margin:0;font-size:.7em;font-family:Verdana, Arial, Helvetica, sans-serif;background:#EEEEEE;} fieldset{padding:0 15px 10px 15px;}

これの最も一般的な原因は maxAllowedContentLength 設定(IISの場合)です

  • 小さすぎる、または

  • 未設定のままで、デフォルトは30000000バイト (<30 Mb)

そのため、maxAllowedContentLength より大きいアーティファクトはIISによって破棄されます。設定値を確認して、ビルドを再実行してください。

プレリリースパッケージはTeamCity NuGetフィードに表示されません

問題 : プレリリースパッケージはTeamCity NuGetフィードに表示されません。

原因 : パッケージバージョンが必要な形式(英語)に違反している場合、NuGetクライアントバージョン3より前はプレリリースパッケージのリストに失敗します。

ソリューション : 必要な形式(英語)に違反するバージョンのビルドアーティファクトを削除します。

TeamCity NuGetフィードでパッケージのインデックス作成が遅い

問題 : TeamCityサーバーホストマシンをTeamCity 2017.1ビルドメタデータに移動またはアップグレードした後でリセットできます。

原因 : TeamCity NuGetフィードはビルドメタデータに依存しており、パッケージの再インデックス作成はパッケージの数とTeamCityサーバーのアイドル時間によっては多くの時間がかかります。

ソリューション : メタデータの再インデックス作成を高速化するには、以下の内部プロパティを指定します。

teamcity.buildIndexer.indexPackSize=1000 teamcity.buildIndexer.packSleepDurationMs=10

メタデータのインデックス作成の進行状況を確認するには、teamcity-server.logファイルで次のような行を探します。

INFO - .index.BuildIndexer (metadata) - Enqueued next 100 builds for indexing, builds left: 7064, last build id: 8142

インデックスの再作成が完了したら、これらの内部プロパティを削除します。

TeamCityからHTTPSに接続する際のSSLの問題(ハンドシェイクアラート): 認識されていない名前)

この課題は、JVMを1.6から1.7に変更し、いくつかの誤って構成されたHTTPSサーバーを接続するときに発生する可能性があります。この課題とその回避策については、この課題(英語)で説明します。

MS SQL ServerとTeamCityを接続するSSLの問題

MS SQL Serverは常にjdbcクライアント(TeamCityアプリケーション)とサーバーとの間にSSL接続を確立するため、接続の問題が発生する可能性があります(SQL例外:Connection reset)。

影響を受けるMS SQLのバージョン

下記のバージョンより前のバージョン

  • SQL Server2012製品版以降

  • SQL Server2008Service Pack 3累積アップデート4

  • SQL Server 2008 R2 Service Pack 1累積アップデート6

  • SQL Server 2008R2サービスパック2

原因 : この問題は、このセキュリティ脆弱性(英語)に対処するJava 1.6更新が原因です。

ソリューション : Microsoft SQL Serverアップグレードをお勧めします。

回避策 : 何らかの理由でMicrosoft SQL Serverのアップグレードが不可能な場合は、データベース接続をSSLまたはTLSで暗号化したまま、古いバージョンのMicrosoft SQL Serverを使用するようにTeamCityを設定できます。

  • AES_128_CBC3DES_EDE_CBCなどのブロック暗号を引き続き使用しますが、-Djsse.enableCBCProtection=false Javaコマンドラインオプション( ここで説明されているように、TEAMCITY_SERVER_OPTS 環境変数に追加できる)を介してCBC保護を無効にします。jsse.enableCBCProtection Javaシステムプロパティは、すべてのOpenJDK 8バージョンとIBM J9 8.0.0 SR1(英語)以降。TeamCityMicrosoft SQL Server間の安全な接続は安定していますが、BEASTとしても知られるCVE-2011-3389(英語)に対して脆弱です。

  • RC4_128などのストリーム暗号(BEASTの影響を受けにくい)にフォールバックします。これにより、接続がCVE-2015-2808(英語)に対して脆弱になります。

JetBrainsに課題を報告する前に、ウイルス対策ソフトウェアをアンインストールして実行してください。例: 課題(英語)を参照してください。

エージェントの再インストール中に歪んだ構成ウィンドウ

異なるバージョンのJavaがすでにインストールされているエージェントの上にWindowsエージェントインストーラーを介してTeamCityエージェントをインストールすると、「ビルドエージェントのプロパティを構成する」インストールウィンドウがゆがんで表示される場合があります。

この課題はTeamCity 2019.1.5で修正されました

2019.1.5にアップグレードせずにこの課題を回避するには、同じディレクトリに新しいエージェントをインストールする前に、以前にインストールしたエージェントバージョンをアンインストールします。
エージェントをアンインストールするには、エージェントホームディレクトリUninstall.exe を呼び出し、すべての「除去...」チェックボックスをオフにしてエージェントのログと設定を保持し、アンインストールをクリックします。アンインストールが正常に完了したら、エージェントインストーラーを介して新しいエージェントバージョンのインストールを続行できます。

Windows Dockerコンテナー

TeamCity Dockerコンテナーイメージに共通の問題。

  • KB4340917(英語)を使用したWindows 10バージョン1803以降、コンテナーからローカルホストへのポートマッピングを使用することが可能です。以前のWindowsバージョンでは、このマシンに関連付けられている非ローカルホストのIPアドレスに対して機能します。マシンのホスト名を使用して実行中のアプリケーションにアクセスするか、ipconfig コマンドを使用してIPアドレスを決定できます。実際には動作しますが、netstat -an コマンドではポートがどのIPアドレスでも開いていることが示されない場合があります。これはWindows上のDockerの既知の問題でもあります。

  • Windows 10では、コンテナーごとに割り当てられるメモリはデフォルトで1GBです。この値を増やすには、以下のメモリオプションを使用します。

    docker run ... -m 2GB -e TEAMCITY_SERVER_MEM_OPTS="-Xmx2g -XX:ReservedCodeCacheSize=350m"
  • Windows 10ではコンテナーはHyper-V経由で動作し、ネットワークや他のサブシステムで問題が発生する可能性があります。これらの問題を診断するには、次のPowerShellスクリプトを実行してください。

    Invoke-WebRequest https://aka.ms/Debug-ContainerHost.ps1 -UseBasicParsing | Invoke-Expression
  • Windows DockerイメージからTeamCityサーバーを開始するときは、必ず、ボリュームとして使用されるディレクトリに対してフルコントロール認証されたユーザーを付与してください。関連号を見る(英語)

  • ディレクトリ C:/BuildAgent/work をボリュームとしてコンテナーホストにマップしてWindows Dockerコンテナーを起動すると、Git for Windowsは次のエラーで失敗します: "無効なパス '/ ContainerMappedDirectories': そのようなファイル、又はディレクトリはありません"。回避策は、C:/BuildAgent/work をボリュームとして追加しないことです。

スクリプト出力を分析するには、次のドキュメント(英語)を参照してください。コンテナーネットワークサブシステムに問題があることが示されている場合は、クリーンアップスクリプト(英語)を使用してリセットしてみてください。

Windows用Dockerのトラブルシューティングに関する詳細は、Docker(英語)およびマイクロソフト(英語)のドキュメントにあります。

WindowsにインストールされたDockerサーバーOSに関する情報がエージェントにない

Windows 10では、DockerサーバーはHyper-Vサービスに依存しており、その起動にはかなりの時間がかかる場合があります。この課題を解決するには、Windowsサービス用のDocker、デフォルトでは com.docker.service に依存するようにTCBuildAgent Windowsサービスを構成します。

Windows上のLinux Dockerコンテナー

TeamCity 2017.2以降、DockerラッパーはWindowsベースのコンテナーが起動されたときにWindows上で動作します。

LinuxコンテナーがWindowsマシンで起動されている場合、TeamCityは「WindowsでのLinux Dockerコンテナーの起動はサポートされていません。この問題を回避するには、 teamcity.agent.jvm.os.name にWindows エージェントの要件は含まれません」というエラーメッセージを表示します。

DockerラッパーがWindowsプラットフォームでLinuxコンテナーを実行する場合のユースケースをサポートする必要がある場合は、TW-51820(英語)で関連するコメントに投票してください。

Windowsコンテナーの現地時間の問題

Windows Dockerコンテナーを使用する場合、コンテナー(英語)のシステム時刻がホストマシンの時刻と同期しなくなると、Windowsコンテナーの時刻が正しく(英語)なくなる課題があります。応答時間が重要な統合(OAuthトークンなど)で課題が発生する可能性があります。

この問題を解決するには、ホストマシンをWindows Server 2019 / Windows 10 1809にアップグレードし、TeamCity dockerイメージWindowsコンテナー1809と互換性(英語)があります。を使用してください。

コンテナーの起動時に「アクセスが拒否されました」または「パスへのアクセスが拒否されました」問題

Dockerは、プロセス分離を使用してWindowsコンテナーを開始するときに、Dockerボリュームを含むディレクトリへの書き込みアクセス権がないWindowsユーザーアカウントを使用します。この場合、「パスへのアクセスが拒否されました」または「アクセスは拒否されました」エラーのために、ビルドエージェントの起動に失敗する場合があります。

この課題を解決するには、%\PROGRAMDATA%\docker\volumes ディレクトリの「Authenticated Users」グループに「フルコントロール」権限を付与します。

dotCoverの既知の課題

dotCoverはWindows Nano Serverをサポートしていません

Nano Server OSを搭載したエージェントでdotCoverを実行しようとすると、ビルドは終了エラー「コード-1073741515でプロセスが終了しました」で失敗します。Nano Serverの代わりに、Windows Serverの代替最小インストールオプションであるサーバー・コア(英語)の使用を検討してください。

dotCoverはmsbuildのカバレッジ統計をサポートしていません

dotCoverは、dotnet msbuild /t:vstest コマンドのカバレッジ統計の収集をサポートしていません。代わりに dotnet test を使用してください。

テスト設定を使用したコードカバレッジ構成は廃止されました

テスト設定を使用したコードカバレッジ設定は、dotCoverで廃止されます。Microsoftドキュメントのさらに読み込む(英語)

.testsettings ファイルを使用する場合、TeamCityはログに警告メッセージを表示します。この課題を防ぐには、代わりに.runsettings(英語)ファイルを使用することをお勧めします。何らかの理由で .testsettingsの使用を継続する必要がある場合は、TeamCityエージェントにdotCoverバージョン2019.1.x以前をインストールします(こちらを参照)

Xcode 10は、カスタム出力ディレクトリのアーティファクトをクリーニングできません

Xcodeにカスタム出力ディレクトリを使用する場合、Xcode 10へのアップグレード時に、Xcode Projectビルドランナーを使用したTeamCityビルドがエラーで失敗する場合があることに注意してください: " <ディレクトリ>は、ビルドシステムによって作成されたものではなく、派生データのサブフォルダーではないため、削除できませんでした。

これは、次のXcode 10の既知の課題が原因です。
派生データディレクトリ外のカスタマイズされたビルド場所を使用し、Xcode 10より前の古いビルド製品が含まれるプロジェクトで xcodebuild clean を実行すると、Xcodeは、新しいビルドシステムで作成されていないディレクトリを削除しないことを示すエラーを報告する場合があります。(40427159)
詳細については、Xcodeドキュメント(英語)を参照してください。

この課題を解決するには、代わりにXcode 11を使用することをお勧めします。Xcode 10でこの課題を回避するには、出力ディレクトリを手動でクリーンアップするか、-UseNewBuildSystem=NO をコマンドラインパラメーターに渡して以前のビルドシステムを使用してみます。

TeamCityバージョンごとの課題

2020.1 既知の問題

.NET runner is not compatible with obsolete external .NET CLI Support plugin

The reworked .NETビルドランナー is not compatible with the obsolete external .NET CLI Support(英語) plugin (used in versions 2017.1 and earlier). If the obsolete plugin is installed on your server, you will get the Error creating bean with name "jetbrains.buildServer.dotnet.DotnetRunnerRunType" after updating to TeamCity 2020.1. To solve this issue, please uninstall the obsolete plugin from your server.

Note that all the existing .NET CLI Support build steps are automatically switched to the new .NET runner on updating to TeamCity 2019.2.3 or later. For more information, refer to our upgrade notes.

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

The Jira Cloud API, used by the new Jira Cloud integration build feature, requires sending a server URL in a specific format. Because of that, the build feature does not support VCSs like Perforce, TFS, and SVN out of the box.

To address this issue, we have updated the responsible plugin, and you can find it attached to the related issue(英語) in our tracker. Please download the fixed plugin and install it as described here.
The bundled Jira Cloud plugin will be automatically updated with this fix in our next release.

The feature might also fail to resolve some Git paths that do not correspond to the format expected by the Jira Cloud API. In this case, you can either change the URL manually (for example, from git@<vcs_address>:<workspace_ID>/<repo_name>.git to ssh://git@<vcs_address>/<workspace_ID>/<repo_name>.git ) or download the fixed plugin as described above.

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

Currently, the new Jira Cloud integration build feature supports only atlassian.net domains. We have added the support of the legacy jira.com domain in the fixed version of the responsible plugin. If your Jira Cloud server resides on the jira.com domain, you can download the plugin, attached to the related issue(英語), and install it as described here.
The bundled Jira Cloud plugin will be automatically updated with this fix in our next release.

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

To be able to sign in to Slack from TeamCity, you need to specify all the possible URIs of the TeamCity server as Redirect URLs in the Slack app's settings.
If you use nginx to set up TeamCity behind a proxy server, you might still get the bad_redirect_uri error when trying to establish a connection with Slack. This error is caused by the mismatch between the nginx and Tomcat configuration.

To workaround this issue, download the fixed plugin, attached to the related issue(英語), and install it as described here. Alternatively, you can try updating the Tomcat settings.
The bundled Slack plugin will be automatically updated with this fix in our next release.

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

If you had installed the 2020.1 EAP1 build in terms of our Early Access Program, you might experience problems with signing in to TeamCity via the 組み込み認証 . This issue might occur after upgrading from any 2020.1 EAP version (EAP1 or any later version to which it was upgraded) to the release 2020.1 build.

To workaround this problem, please send the following query to the TeamCity database:

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

2019.2.3既知の課題

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

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

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

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

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

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

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

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

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

2019.2 既知の問題

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

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

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

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

2019.1.4既知の課題

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

この課題はTeamCity 2019.1.5で修正されました。

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

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

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

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

この課題はTeamCity 2019.1.5で修正されました。

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

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