既知の問題

このページには、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" エラーが表示されることがあります。詳細は以下を参照してください。

Windows サービスの制限

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

これらの制限を克服するには、コンソール経由で TeamCity エージェントを実行します。

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

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

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

コンソール経由で TeamCity エージェントを実行します。
デスクトップをロックするスクリーンセーバーを起動しないようにビルドエージェントマシンを設定します。
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 ソフトウェアは、InternetExplorer に表示されるページのレイアウトを破損することが知られています。（TW-13052(英語)）。

Subversion の問題

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

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

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 インストールアップデート (例: Amazon Corretto(英語) の OpenJDK) を使用していることを確認してください。サポートされている Java バージョンのリストについては、サポートされているプラットフォームと環境を参照してください。

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 によって破棄されます。設定値を確認して、ビルドを再実行してください。

IIS を使用したセットアップでのアーティファクトドメインの分離により、アーティファクトへのアクセス時に認証エラーが発生する

TeamCity サーバーでアーティファクトドメインの分離が有効になっている場合、ビルドアーティファクトにアクセスしようとすると 401 Unauthorized エラーが発生する可能性があります。この問題は、IIS Web サーバーのデフォルトの動作によって発生する可能性が最も高く、アーティファクトのドメインからメインサーバードメインにターゲットを絞った応答ヘッダーが書き換えられます。この動作を無効にするには、IIS インターフェースでアプリケーションリクエストルーティング | サーバープロキシ設定に移動し、「応答ヘッダーのホストを逆書き換え」オプションを無効にします。

TeamCity UI にコンテンツがありません

TeamCity ページをロードすると、一部のコンテンツが欠落していることに気づく場合があります。最も一般的には、ビルドが完了したビルド構成にはビルド履歴が表示されず、空のように表示されます。同時に、Web ブラウザーは複数の 404 (見つかりません) エラーをログに記録します。

IIS サーバー上で実行されている TeamCity インスタンスでこれが発生した場合は、IIS maxQueryStringLength 値や maxQueryString 値を確認してください。これらの設定により、クエリ文字列の最大長が制限されます。これらの制限が低すぎる場合、TeamCity が <server-url>/app/rest/... エンドポイントに送信する REST リクエストの一部が失敗する可能性があります。

この問題を解決するには、IIS サーバーの web.config ファイルでこれらの制限を増やします。正確な値は、現在の構成とプロジェクト / 構成 ID の長さによって異なります。一般的な推奨事項として、この制限を 4000 文字に設定し、問題が解決しない場合は徐々に上げてください。

リクエストの制限 | も参照してください。http ランタイム要素

TeamCity から HTTPS に接続する際の SSL の問題（ハンドシェイクアラート）: unrecognized_name)

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

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

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

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

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

Windows での TeamCity サーバーのバージョンが正しくない

TeamCity の自動更新では、関連する Windows レジストリキーに新しいバージョン番号を書き込めない場合があります。これにより、標準の Windows プログラムの追加または削除アプリケーションは、更新後に変更されない初期 TeamCity インストールのバージョンを表示します。

レジストリキーを手動で更新して正しいバージョンを設定するには、TeamCity 管理 | 更新ページの指示に従って、TeamCity インストールに同梱されている PowerShell スクリプトを実行します。

runas /user: Administrator "powershell -File C:\TeamCity\bin\update-registry-version.ps1"

Windows Docker コンテナー

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

KB4340917(英語) を搭載した Windows 10 バージョン 1803 以降では、コンテナーから localhost へのポートマッピングを使用できます。以前の Windows バージョンでは、このマシンに関連付けられた非 localhost IP アドレスに対して機能し、マシンのホスト名を介して実行中のアプリケーションにアクセスしたり、ipconfig コマンドを介して IP アドレスを特定したりできます。netstat -an コマンドでは、実際には機能しているにもかかわらず、どの IP アドレスでもポートが開いているとは表示されないことに注意してください。これは、Windows 上の Docker の既知の問題でもあります。
Windows 10 では、コンテナーごとに割り当てられるメモリはデフォルトで 1GB です。この値を増やすには、以下のメモリオプションを使用します。
docker run ... -m 6GB --cpus=4 -e TEAMCITY_SERVER_MEM_OPTS="-Xmx3g -XX:ReservedCodeCacheSize=640m"
Windows 10 ではコンテナーは Hyper-V 経由で動作し、ネットワークや他のサブシステムで問題が発生する可能性があります。これらの問題を診断するには、次の PowerShell スクリプトを実行してください。
Invoke-WebRequest https://aka.ms/Debug-ContainerHost.ps1 -UseBasicParsing | Invoke-Expression
Windows Docker イメージから TeamCity サーバーを開始するときは、必ず、ボリュームとして使用されるディレクトリに対してフルコントロールに認証されたユーザーを付与してください。関連号を見る (英語)
ディレクトリ C:/BuildAgent/work がボリュームとしてコンテナーホストにマップされた状態で Windows Docker コンテナーを起動すると、Windows 用の Git が次のエラーで失敗します: " 無効なパス '/ContainerMappedDirectories': そのようなファイル、又はディレクトリはありません "。回避策は、C:/BuildAgent/work をボリュームとして追加しないことです。

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

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

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

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

Linux Docker Windows のコンテナー

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

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

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

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

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

これを解決するには、ホストマシンを Windows Server 2019 /Windows 10 1809 にアップグレードし、TeamCity docker images Windows コンテナーと互換性があります 1809(英語) を使用します。

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

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

この問題を解決するには、docker run コマンドで ..\TeamCity\temp ディレクトリの専用ボリュームマッピングを指定してください。また、このプロセスに十分な量のリソースが割り当てられていることを確認することをお勧めします。

docker run --memory="6g" --cpus=4 -e TEAMCITY_SERVER_MEM_OPTS="-Xmx3g -XX:MaxPermSize=270m -XX:ReservedCodeCacheSize=640m" --name teamcity-server-instance
    -v <path-to-data-directory>:C:/ProgramData/JetBrains/TeamCity 
    -v <path-to-logs-directory>:C:/TeamCity/logs  
    -v <path-to-temp-directory>:C:/TeamCity/temp  
    -p <port-on-host>:8111 jetbrains/teamcity-server

あるいは、%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\> はビルドシステムによって作成されておらず、派生データのサブフォルダーでもないため、削除できませんでした。"

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

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

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

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

Google Chrome で、chrome://flags ページを開き、「SameSite のデフォルトの Cookie」オプションを無効にします。
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 Studio 2017 ビルドを使用している場合、ロガーのインスタンスを作成できません

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

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

.rsp ファイルの解析 (エラー MSB1006: プロパティが無効です)

Microsoft によってコア System.CommandLine ライブラリに導入された重大な変更(英語)により、プロパティ値にコンマまたは（または）セミコロンが含まれる .rsp ファイルは正しく解析されません。この問題を回避するには、システムプロパティの値を引用符で囲んでください。この解決策がプロジェクトに適用できない場合は、teamcity.internal.dotnet.msbuild.parameters.escape 構成パラメーターを追加し、その値を " 真実 " に設定してください。この設定を有効にすると、TeamCity はユーザー定義プロパティの値を自動的に引用符で囲みます。

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 パラメーターを使用します。

NuGet フィードにパッケージが見つかりません

問題 : すべてのパッケージが NuGet フィードに見つかるわけではありませんが、アーティファクトはディスク上と UI に存在し、teamcity-nuget.log はパッケージのインデックス作成が進行中であることを示しません。

原因 : 考えられる原因の 1 つは、TeamCity がバックアップから復元されたか、新しいサーバーに移動されたことです。

ソリューション : buildsMetadata キャッシュをクリアし、サーバー上でパッケージの再インデックスが完了するまで待機します。ビルド履歴が長い大規模なサーバーでは、時間がかかる可能性があることに注意してください。

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

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

VCS 変更のロード中にエラーが発生しました

TeamCity サーバーの起動時の VCS 変更のロード中にエラーが発生しましたは、MySQL で有効になっているカーソルベースのストリーミングに関連している可能性があります。このエラーを防ぐには、database.properties で connectionProperties.useCursorFetch プロパティを false に設定して、サーバーを再起動してください。
詳細については、この課題(英語)を参照してください。

プルリクエストビルド機能の既知の問題

場合によっては、TeamCity は、JetBrains Space で古いオープンマージ要求に基づいてビルドを開始し、Bitbucket クラウドで要求をプルすることができます。これは、次の一連の手順で再現されます。
1. オープンマージリクエストでリポジトリに接続する新しい VCS ルートを作成します。デフォルトのブランチ仕様のままにします。
2. この VCS ルートと VCS トリガーを使用してビルド構成を作成します。
3. ブランチ仕様を VCS ルートから削除します。
4. プルリクエストビルド機能をビルド構成に追加します。
5. プルリクエスト機能を無効にしてから、再度有効にします。
詳細については、関連する問題(英語)を参照してください。
プルリクエストビルド機能は、JetBrains Space のマージ要求タイムラインに間違ったビルドステップ番号を投稿する可能性があります。関連する問題(英語)を参照してください。

Git 2.35.2 で導入されたより厳格なリポジトリ所有権チェック(英語)により、TeamCity サーバーの Git をこのバージョンまたはそれ以降のバージョンに更新すると、誤動作が発生する可能性があります (たとえば、" 致命的: リモートリポジトリから読み取れませんでした " メッセージ)。一時的な解決策として、次の回避策を試してください。

TeamCity サーバーが Linux 上で実行されている場合は、<TeamCity データディレクトリ>/system/caches/git ディレクトリを含むボリュームが、このディレクトリにアクセスするために TeamCity が使用するのと同じユーザーでマウントされていることを確認してください。
Windows Docker イメージを介してインストールまたは更新された TeamCity サーバーで関連する問題が発生した場合は、ネイティブ Git を無効にして、TeamCity サーバーが代わりに JGit を使用するように強制します。

ネイティブ Git チェックアウトの既知の問題

これらの問題は、バージョン 2022.04 以降に有効な TeamCity サーバーへのソースをチェックアウトするためのネイティブ Git の使用に関係しています。

SSHDSA キーはネイティブ Git では機能しません

サーバーをネイティブ Git に切り替えると、SSHDSA キーを介したリポジトリでのビルドの承認に失敗します。関連する問題 TW-74580(英語) を参照してください。

この問題を回避するには、teamcity.git.sshCommandOptions 内部プロパティを -o "PubkeyAcceptedKeyTypes=+ssh-dss" に設定してください。

OpenSSH 経由のネイティブ Git は失敗する可能性があります

サーバー / エージェントのインストールパスにスペースが含まれている場合、OpenSSH を介したネイティブ Git が Windows で失敗する可能性があります。関連する問題(英語)を参照してください。

ssh プロキシの nonProxyHosts オプションは使用できません

TeamCity は、ネイティブ Git を介して接続するときに ssh プロキシを使用します。関連する問題(英語)を参照してください

カスタム SSL 証明書はネイティブ Git ではサポートされていません

サーバー上のネイティブ Git のカスタム SSL 証明書のサポートは利用できません。関連する問題(英語)を参照してください

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

アーティファクトをサードパーティの S3 互換ストレージに公開すると失敗する可能性があります

TeamCity 2022.04 は Amazon S3 アーティファクトストレージに関連する ACL 設定(英語)を変更します。これにより、Backblaze などのサードパーティの S3 互換ストレージへのアーティファクトの公開が失敗する可能性があります。

TeamCity 2022.04 に更新した後にこの問題を修正するには、関連する問題(英語)からプラグインバージョンをダウンロードし、必要な acl 値を使用して storage.s3.acl 構成パラメーターを追加します。ここにリストされているすべての値がサポートされています。

アーティファクト解凍の問題

通常の ZIP 形式では、最大 2 ^{32 バイト（4GB）のサイズです。ビルドによってこの値を超えるアーティファクトが生成される可能性があるため、TeamCity は 2 バイトまでのアーカイブをサポートする ZIP64 形式でアーティファクトを圧縮します。} 64 バイト (16 エクサバイト) のアーカイブがサポートされます。

TeamCity ビルドアーティファクトの解凍に使用するツールが ZIP64 をサポートしていない場合 (たとえば、ヘッダーエラーの警告が表示される場合があります)、次の構成パラメーターをプロジェクト (<ルートプロジェクト> またはサポートされていないアーカイブを生成する特定のプロジェクト) に追加します。:

teamcity.internal.artifacts.useZip64=Never
teamcity.internal.artifacts.useByteChannelForZip=false

macOS エージェントの空きディスク容量が誤って報告される

TeamCity/macOS エージェントが報告するディスク空き容量は、ネイティブシステムツールが表示する容量と異なる場合があります。この値がビルドに必要な最小値を下回る場合、TeamCity は一時ファイルの消去を試みます（消去できない場合はビルドが失敗します）。

回避策として、すべての macOS エージェントで次のスクリプトを実行する毎日のメンテナンス構成を設定できます。

dd if=/dev/zero of=dummy status=none bs=64m 2>/dev/null; rm dummy

このスクリプトは、残りのディスク領域をダミーファイルで埋めてから削除し、より正確な空き領域の読み取りを促します。

object MacOSDiskSpace : BuildType({
    name = "macOS disk space workaround"

    steps {
        script {
            id = "simpleRunner"
            scriptContent = "dd if=/dev/zero of=dummy status=none bs=64m 2>/dev/null; rm dummy"
        }
    }
    triggers {
        schedule {
            schedulingPolicy = daily { hour = 3 }
            branchFilter = ""
            triggerBuild = always()
            triggerBuildOnAllCompatibleAgents = true
        }
    }
    requirements {
        contains("teamcity.agent.jvm.os.name", "Mac OS")
    }
})

詳細については、この YouTrack チケットを参照してください: TW-93698(英語)。

2026 年 3 月 08 日