TeamCity 2020.2 ヘルプ

既知の問題

このページには、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 start を介して)構成します)。

グラフィカルテストの場合、ビルドエージェントをサービスとして開始することはできません。ユーザーの自動ログオン後 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 デーモンを使用している)場合、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

矛盾するソフトウェア

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

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

ESET アンチウイルスは、Ant/IntelliJ IDEA プロジェクトのビルドを大幅に遅くする可能性もあります(エージェント上のローカルホストへの 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 より遅くなるかもしれません。追加情報については、当社の issue tracker の該当する号を参照してください。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 サーバーからのダウンロードが遅い

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 から HTTPS に接続する際の SSL の問題(ハンドシェイクアラート): unrecognized_name)

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

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

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

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

以下にリストされているものより前のバージョン:

  • SQL Server2012 製品版以降

  • SQL Server 2008 Service Pack3 累積アップデート 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(英語) に対して脆弱になります。

  • 一時的に無効にされたウイルス対策ソフトウェアを使用して実行することを検討してください。ただし、これによってセットアップのセキュリティが損なわれないようにしてください。例: この問題(英語)を参照してください。

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

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

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

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

Windows Docker コンテナー

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

  • KB4340917(英語) を搭載した Windows10 バージョン 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 コンテナー

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 ビルドが次のエラーで失敗する可能性があることに注意してください: 「 <directory> はビルドシステムによって作成されていないため、削除できませんでした。派生データのサブフォルダーではありません。」

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

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

クロスサーバープロジェクトのポップアップメニューが最新のブラウザーで機能しない場合がある

SameSite Cookie(英語) サポートの最近の更新により、一部の最新の Web ブラウザーではプロジェクトポップアップメニューにクロスサーバープロジェクトが表示されない場合があります(Chrome プラットフォームの詳細(英語)を参照してください(英語))。

クロスサーバープロジェクトメニューにアクセスできない場合は、ブラウザーの設定を変更して、この問題を一時的に回避することができます。

  • Google Chrome で、chrome://flags ページを開き、デフォルトの Cookie で SameSite オプションを無効にします。

  • Mozilla Firefox で about:config ページを開き、network.cookie.sameSite.laxByDefault オプションを無効にします。

  • Safari で、環境設定 | プライバシーに移動し、クロスサイト追跡を防止するオプションを無効にします。

この問題は、TeamCity 2020.1.5 アップデートで解決されます。詳細については、関連する問題(英語)を参照してください。

.NET ランナーの既知の問題

.NET ランナーは廃止された外部 .NET CLI サポートプラグインと互換性がありません

再加工された .NET ビルドランナーは、廃止された外部プラグイン .NET CLI サポート(英語)(バージョン 2017.1 以前で使用)と互換性がありません。廃止されたプラグインがサーバーにインストールされている場合、TeamCity 2020.1 に更新した後、「jetbrains.buildServer.dotnet.DotnetRunnerRunType」という名前の bean の作成中にエラーが発生します。この問題を解決するには、廃止されたプラグインをサーバーからアンインストールしてください。

TeamCity 2019.2.3 以降に更新すると、既存のすべての .NET CLI サポートビルドステップが新しい .NET ランナーに自動的に切り替えられることに注意してください。詳細については、アップグレードノートを参照してください。

初期の Visual Studio2017 ビルドを使用している場合、ロガーのインスタンスを作成できません

まれに、Visual Studio 2017 の初期ビルドがビルドエージェントにインストールされている場合、「ロガーのインスタンスを作成できません」というメッセージが表示されることがあります。.NET ビルドステップの実行時にエラーが発生しました。これは、使用されているフレームワークバージョンとのロガーの非互換性が原因である可能性があります。

この問題を回避するには、Visual Studio 2017 を最新のビルドにアップグレードするか、またはそれ以降のバージョンの .NET フレームワークをインストールします。

NuGet の既知の問題

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

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

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

解決策 : バージョンが必要な形式(英語)に違反しているビルドアーティファクトを削除します。

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

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

原因 :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

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

NuGet は最近のパッケージバージョンをプルしません

問題 :NuGet は、フィードからこれらのパッケージをプルするときに、最近のバージョンのパッケージをスキップすることがあります。

原因 :NuGet はサーバーの応答をキャッシュするため、プルしてもフィードの最新の変更は検出されません。

解決策 : 新しいリクエストをキャッシュではなくサーバーに直接送信するには、リクエストで --no-cache パラメーターを使用します。

PowerShell で複数行パラメーターを使用することはできません

以前のバージョンの PowerShell ランナーは、複数行の引数の受け渡しをサポートしていません。バージョン 2020.1.4 以降、teamcity.powershell.arguments.multiline=true 構成パラメーターを設定することにより、このサポートを有効にできます