よくある問題

ビルドはローカルで機能しますが、失敗するか TeamCity で誤動作する

TeamCity でビルドが失敗したかその他の方法で誤動作したが、そうしてはいけないと思われる場合、最初にすることは問題が TeamCity に関連しているかどうかを確認することです。

これを行うには、次の手順に従います。

1. コマンドプロンプトからタスクを実行する方法を見つけます。TeamCity エージェントが実行されているのと同じユーザーで、エージェントが受信するのと同じ環境で、TeamCity エージェントマシン上で機能することを確認してください。必要に応じて、別のユーザーで TeamCity エージェントを実行するか、その環境を微調整してください。

2. コマンドが正常に実行されたら、カスタムスクリプト設定でコマンドラインランナーを使用して、TeamCity ビルドで同じコマンドを構成します。

3. それがうまくいく場合は、それが該当すると思われる場合は別のランナーを試してください。

アプローチの詳細は以下のとおりです。

TeamCity エージェントと同じマシン上で、エージェントが実行されているのと同じユーザーで、同じ環境変数と同じ作業ディレクトリ、同じアーキテクチャー（32/64 ビット）のコマンド行を使用して実行すると、コマンドプロンプトからビルドが正常に実行されることを確認します。

TeamCity ビルドエージェントがサービスとして実行されている場合 (たとえば、Windows サービスとしてインストールされている場合)、コマンドラインから管理者権限を持つ通常のユーザーとして TeamCity エージェントを実行してみてください。Windows サービスの制限も参照してください。

これで問題が解決した場合は、サービスで実行することがビルドに問題となる理由を突き止めることができます。ほとんどの場合、これはサービス固有の問題であり、TeamCity とは直接関係ありません。また、TeamCity エージェントを常にコンソールから実行するように設定することもできます (たとえば、自動ユーザーログオンを構成し、ユーザーログオン時にエージェントを実行します)。

コマンドラインからビルドを実行するために使用できる詳細な手順は次のとおりです。

失敗している TeamCity で構成されたビルドがあると仮定して、以下を実行してください。

• TeamCity でビルドを実行して、動作がおかしい

• 他のビルドが実行されないようにエージェントを無効にします。これはビルドがまだ進行中の間に行うことができます

• TeamCity エージェントを実行しているユーザーと同じユーザーを使用して、エージェントマシンにログインします。(マシンプロセスリストで正しいユーザーを確認してください)

• エージェントを停止する

• コマンドラインコンソールで、問題のビルドのチェックアウトディレクトリへの cd (ディレクトリは TeamCity のビルドログの始めで調べることができます)

• 開発者のマシンで行うのと同じように、コマンドラインでビルドを実行します。これはランナー依存です。(一部のランナーについては、ビルドログで TeamCity が使用するコマンドラインを検索できます。TeamCity が使用するコマンドラインについては、logs\teamcity-agent.log ファイルも参照してください。)

• ビルドが失敗した場合 — 問題はおそらく TeamCity に関連しておらず、マシンで調査する必要があるため、理由を調査してください。

• 正常に実行された場合は、続行します

• 同じコンソールウィンドウで cd を <TeamCity agent home> /bin ディレクトリに移動し、そこから agent start コマンドを使用して TeamCity エージェントを起動します。

• TeamCity のランナー設定が適切であることを確認し、手動で使用したのと同じコマンドラインを生成する必要があります。例: カスタムスクリプトオプションと .sh または .bat ファイルに保存してコマンドプロンプトから実行できる同じコマンドでコマンドラインビルドステップを使用する

• TeamCity でビルドを実行し、カスタムビルドの実行でエージェントを選択しますダイアログ

• 終了したら、エージェントを有効にします

ビルドがコンソールから成功しても TeamCity で失敗する場合は、TeamCity のコマンドラインランナーを使用してコンソールと同じコマンドを起動します。

それでも TeamCity で異なる動作をする場合、おそらくこれは環境またはツールの問題です。

コマンドラインランナーは機能するが、オプションがすべて同じであるのに専用ランナーが機能しない場合は、ケースの詳細を示す新しい問題をトラッカー(英語)に作成します。すべてのビルドステップ設定、ビルドログ、ビルドをカバーするすべてのエージェントログ、ビルドを実行するためにコンソールで使用したコマンド、ビルドの完全なコンソール出力を添付してください。

TeamCity ではビルドが遅い

ビルドが遅い場合は、まずビルドログをチェックして、時間のかかる操作があるかどうか、時間がプロセス全体に分散しているかどうかを確認します。遅いビルドと速いビルドのビルドログを比較して、違いが何であるかを把握できます。また、上記のように同じマシンのコンソールからビルドを実行して、コンソールから実行したビルドと TeamCity でのビルドに違いがあるかどうかを確認することもできます。

処理の遅延がすべての操作に及んでいる場合は、ビルド中にエージェントマシンのリソース（CPU、ディスク、メモリ、ネットワーク）を分析し、いずれかのリソースにボトルネックが発生していないかを確認する必要があります。パフォーマンスモニタータブを使用すると、ビルドによって使用される CPU、メモリ、ディスク I/O の量と、どの段階で使用されているかを確認できます。

ビルドプロセスがハングアップしている場合は、実行中のビルド結果ページにあるスレッドダンプを表示リンクをクリックすると、その理由がわかります。

長時間の操作があり、それが TeamCity 関連のもの (実際のビルドプロセスの開始前または終了後) である場合、TeamCity エージェントとサーバーを分析する必要があります (ログとスレッドダンプ)。

この問題について私たちに相談したい場合は、目に見える影響を説明し、調査プロセスを詳しく説明し、ビルドログ、完全なエージェントログ、収集されたその他のデータを接続してください。

ビルドを実行するために、開始済みビルドエージェントをサーバー上で使用できない

インストール後のエージェントの最初の起動または TeamCity サーバーのアップグレード / プラグインのインストールは、エージェントがサーバーから更新をダウンロードして自動アップグレードするため、時間がかかる場合があります。

通常、エージェントは、エージェント / サーバーのネットワーク接続速度にもよりますが、1 〜 10 分で接続されるはずです。

その時間内にエージェントが接続されない場合は、エージェントの名前（conf\buildAgent.properties ファイルで構成されている）を確認し、エージェントページのタブを確認してください。

• エージェントは接続済みにあります。エージェントはビルドを実行する準備ができています

• エージェントは切断中です — エージェントはサーバーに接続されていましたが、切断されました。表の「非アクティブの理由」を確認してください。理由が「エージェントが登録解除されました (アップグレードします)」の場合は、さらに数分間待ちます

• エージェントは未承認にあります。サーバーに初めて接続するすべてのエージェントは、サーバー管理者によって承認される必要があります

エージェントが 10 分以上状態を維持し、エージェントとサーバー間のネットワーク接続が速い場合は、以下の手順を実行します。

• 関連するエージェントマシンを調べて、エージェントプロセスが実行されていること、および conf\buildAgent.properties 内の serverURL が正しいこと（およびサーバーがその URL からマシンから到達可能であること）を確認します。

• 関連する環境要件がすべて満たされていることを確認します。

• エージェントログ (teamcity-agent.log、launcher.log、upgrade.log) で関連するメッセージやエラーを確認します。

• エージェント名または IP が記載されたメッセージやエラーがないか、サーバーログ (teamcity-server.log) を確認します。

エージェントのアップグレードが遅れた原因がログに見つからない場合は、お問い合わせいただき、エージェントとサーバーの完全なログを提供してください。エージェントマシン上のエージェントプロセス（java プロセス）の状態を必ず確認 / 含めてください。

ビルドのアーティファクトは消去されません

サーバーのクリーンアッププロセスによって削除されるはずのアーティファクトが保持されている場合は、以下を確認してください。

• ビルド構成のクリーンアップ規則、アーティファクトセクション

• ビルド履歴行に「このビルドは他のビルドで使用されています」というアイコンが表示されている (ビルド履歴のピンアクション / アイコンの前)

• build の Dependencies タブの " アーティファクトのアーティファクト " のセクション。すべてのビルド構成について、「依存関係のあるアーティファクトのクリーンアップを防止する」がオンになっているかどうかを確認します（これはデフォルト値です）。そうであれば、その設定のためにビルドのアーティファクトは消去されません。

クリーンアップ設定の詳細を参照してください。

データベース関連の問題

一般的な Maven の問題

TeamCity ビルド構成でよく見られる Maven 関連の問題には、次の 2 種類があります。

• ビルド構成の Maven タブにエラーメッセージが表示される: "Maven プロジェクト情報の収集中にエラーが発生しました ..."

• Maven 依存関係トリガーがアクティブ化されたビルド構成のエラーメッセージ: 「Maven 依存関係の更新を確認できません ...」このようなエラーメッセージが表示されているにもかかわらずビルド構成が正常にビルドされる場合、これらのエラーはサーバー側の Maven の設定ミスが原因である可能性があります。

Maven タブの情報を収集するため、または Maven 依存関係チェック (トリガー用) を実行するために、TeamCity は埋め込まれた Maven を実行します。実行はサーバーマシン上で行われ、agent-side maven 設定にはアクセスできません。TeamCity は、Maven のサーバー側設定に従って、サーバー側で settings.xml ファイルを個別に解決します。

server-side settings.xml ファイルにリモートリポジトリ、プロキシ、ミラー、プロファイル、認証情報などに関する正しい情報が含まれているかどうかを確認することは理にかなっています。

「構成ファイル内の重大なエラー」エラー

エラーが発生した場合、TeamCity データディレクトリに保存されている設定が不整合な状態にあることを意味します。これは、ファイルを手動で変更した後、または TeamCity の新しいバージョンが不整合を報告し始めた場合に発生する可能性があります。
この問題を解決するには、サーバーファイルシステム上のメッセージに記載されているファイルを編集します。(手動で編集する前に、必ずファイルのバックアップコピーを作成してください)。通常、変更を有効にするためにサーバーを再起動する必要はありません。

ID "XXX" の VCS ルートが存在しません

ビルド設定またはテンプレートが、システムで定義されていない VCS ルートを参照しています。対処方法: VCS ルートを復元するか、指摘された ID を使用して新しい VCS ルートを作成するか、メッセージに記載されたファイルを編集して、VCS ルートへの参照を削除します。

TeamCity インストールの問題

インストール後に TeamCity Web UI にアクセスできない場合、別のプログラムですでに使用されているポートで TeamCity を実行している可能性があります。確認と設定 TeamCity インストール。

TeamCity NuGet フィードに関する問題

部分的な TeamCity NuGet フィードで問題が発生している場合（たとえば、NuGet パッケージがない場合）、TeamCity NuGet フィードのインデックスを再作成する必要がある場合があります。

TeamCity にすべての利用可能なパッケージのインデックスを再作成させ、NuGet パッケージリストをリセットさせるには、サーバー管理 | 診断 | キャッシュに移動し、buildsMetadata Reset リンクを使用します。

.NET 関連の TeamCity ツールの問題

手動入力を必要とするツール、特に Extended Validation コード署名を使用する

TeamCity エージェントで実行されるビルド手順中に手動の対話が必要なツールを使用したい場合があります。これは TeamCity 固有の問題ではないため、一般的な手段を使用して対処する必要があります。

Windows では、TeamCity エージェントをサービスとしてではなく、自動ユーザーログオン、関連する詳細を構成することでデスクトップにアクセスできるように構成することをお勧めします。

機能が何らかの理由で組み込まれているため、Extended Validation(EV) コード署名の簡単な解決策はありません。スタックオーバーフロー(英語)の問題についていくつかの議論があります。適切なソリューションは、独自の承認アプローチを使用して専用サービスを実装し、それを介してバイナリに署名するようです。

Tomcat エラー: リクエストヘッダーが大きすぎます

デフォルトでは、Tomcat は要求および応答の HTTP ヘッダーに 4096 バイト (4KB) の制限を設定します。ヘッダーに含まれる Cookie が多すぎる場合 (たとえば、エンドユーザーと TeamCity 間のプロキシサーバーからのもの)、またはそのサイズが大きすぎる場合、ユーザーは TeamCity を参照するときに 400: Request Header too large または 502: Bad Gateway エラーに遭遇する可能性があります。この問題の原因を特定するには、ブラウザー開発者コンソールで影響を受けるヘッダーをインスペクションすることをお勧めします。

この問題を解決するには、$TOMCAT_HOME/conf/server.xml ファイル内のすべての関連コネクターの maxHttpHeaderSize パラメーター値を編集して、Tomcat ヘッダーの制限を増やします。例: 次のサンプルでは、パラメーター値を 65536 に設定して、制限を 64KB に増やします。