既知の課題

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

TeamCity の特定のバージョンに固有の課題を確認するには、アップグレードノートの該当するセクションに移動してください。

JDK 8 update 242+ との非互換性

JDK 8u242+ で実行されている TeamCity の 2019.2.1 までのバージョンでは、たとえば Git 操作や Windows ドメイン認証操作で java.lang.NoClassDefFoundError: クラス 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 [現在のユーザー名] は、そのマシンへのそのユーザーのすべての接続を、コンソールまたはグラフィカルのいずれかとして一覧表示します。
rdp-tcp#* として一覧表示されるものはリモートデスクトップ接続であり、 tscon [接続 ID] /dest:コンソール を使用してコンソールにリダイレクトできます。

.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 に自分でパッチを適用できます。 mvn.bat の 148 行目にあるフラグメントを置き換えてください：

: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 より遅くなる場合があります。追加情報については、課題トラッカーの該当する課題を参照してください: 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 アプリケーション

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

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

単一の TeamCity サーバーだけがひとつのデータベースを使用でき、これは TeamCity サーバーの開始時にチェックされます。

起動時の「データベースは使用中です 」エラーは、次のいずれかの場合に報告されます。

同じデータベースに接続された複数の TeamCity サーバーを起動しようとしました
二つ目の 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 が <サーバー URL>/app/rest/… エンドポイントに送信する REST リクエストの一部が失敗する可能性があります。

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

関連項目: リクエスト制限 | httpRuntime 要素

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

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

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

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

この課題は TeamCity 2019.1.5 で修正されています。

2019.1.5 にアップグレードせずにこの課題を回避するには、同じディレクトリに新しいエージェントをインストールする前に、以前にインストールしたエージェントバージョンをアンインストールしてください。
エージェントをアンインストールするには、 アンインストール.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 のドキュメントにあります。

インストール済み Docker サーバー OS に関する Windows 上の情報がエージェントにない

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

Windows 上の Linux Docker コンテナー

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

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

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

Windows コンテナーでのローカル時刻の問題

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

これに対処するには、ホストマシンを Windows サーバー 2019 / Windows 10 1809 にアップグレードし、TeamCity Dockerイメージ 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 サーバーをサポートしていません

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 を渡して以前のビルドシステムを使用してみてください。

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

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

Google Chrome で、 chrome://flags ページを開き、「SameSite のデフォルトの Cookie 」オプションを無効にします。
Mozilla Firefox で about:config ページを開き、 network.cookie.sameSite.laxByDefault オプションを無効にします。
Safari で、環境設定 | プライバシーに移動し、「サイト間トラッキングを防止する」オプションを無効にします。

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

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

.NET ランナーは古い外部 .NET CLI Support プラグインと互換性がありません

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

TeamCity 2019.2.3 以降に更新すると、既存の .NET CLI Support ビルドステップはすべて新しい .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.ログはパッケージのインデックス作成が進行中であることを示しません。

原因: TeamCity がバックアップから復元された、または新しいサーバーに移動された可能性があります。

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

PowerShell で複数行パラメーターを使用できない

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

VCS 変更の読み込み中にエラーが発生しました

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

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

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

Git 2.35.2 で導入されたより厳格なリポジトリ所有権チェックにより、TeamCity サーバーの Git をこのバージョンまたはそれ以降のバージョンに更新すると、不具合が発生する可能性があります (たとえば、 "fatal: could not read from remote repository" メッセージ)。一時的な解決策として、次の回避策を試してください。

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

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

これらの課題は、バージョン 2022.04 以降で有効な、TeamCity サーバーへのソースのチェックアウトにネイティブ Git を使用することに関するものです。

SSH DSA 鍵はネイティブ 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 に更新した後にこの問題を修正するには、関連する課題からプラグインバージョンをダウンロードし、 storage.s3.acl 構成パラメーターを必要な acl 値とともに追加してください。ここに記載されているすべての値がサポートされています。

アーティファクト展開の課題

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

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 年 9 月 11 日