TeamCity 2020.2 ヘルプ

課題の報告

TeamCity の実行で課題が発生し、それらがソフトウェアに関連していると思われる場合は、課題の詳細な説明をご連絡ください

課題を解決するには、システムに関するさまざまな情報とさまざまなログが必要になる場合があります。以下のセクションでは、さまざまな課題についてそのような情報を収集する方法について説明します。

課題を報告する際のベストプラクティス

これらのガイドラインに従うことで、タイムリーな対応と効果的な課題解決が保証されます。適切な連絡方法については、フィードバック(英語)を確認してください。

サポートのリクエストを送信するときは、次の一般情報を含めてください :

  • ビルド番号を含む使用中の TeamCity バージョン(これはフッターと teamcity-server.log にあります)。また、使用されているオペレーティングシステムと Java バージョンを含める価値があります。

  • 課題の発生パターン(初回、繰り返しなど)を記録します。過去に緩和された場合は、最近の環境変更があったかどうかを記録します。具体的に:正確な時間、エラーメッセージを書き留め、予想される動作と実際の動作の両方を記述します。

  • 可能な限り、TeamCity UI の関連するスクリーンショット(常にページ全体とブラウザーの URL をキャプチャーに含める)を含め、関連する設定ファイル、実際の値、REST API エンティティ表現の詳細を提供します。

  • エラーメッセージやその他の関連するテキストメッセージ(イメージではなくテキスト)を含める場合は、完全なメッセージと、それが観察された場所 / 観察されている場所を含めます。メッセージが数行を超える場合は、ファイルとしてチケットに添付します。

  • 3 つ以上のファイルを送信する場合は、ファイルを単一のアーカイブにパッケージ化します。

  • 10Mb を超えるファイルを送信する場合は、大きなデータアーカイブのアップロードのガイドに従ってください。

特定の課題に関するその他の役立つヒント :

  • 必要に応じて、TeamCity サーバーログを使用してアーカイブを添付 / アップロードします(詳細をご覧ください。理想的には、<server_home>\logs ディレクトリ全体にすべてのディレクトリが含まれます。非実用的な場合は、すべてのファイルが発行時刻前後に更新されます)。ビルド時間またはエージェントの動作に関連する場合は、<agent_home>\logs ディレクトリ全体を添付します。

  • パフォーマンス / 遅延 / 遅延の課題については、課題の発生中に(発行時間全体に 10 以上の)サーバーまたはエージェントスレッドダンプのセットを取得し、関連データとともにダンプを送信してください。

  • YouTrack 課題トラッカー(英語)に課題が存在するかどうかを確認することを検討してください。ここでは、ほとんどのバグとエッジ条件を特定します。後の TeamCity バージョンで課題が既に修正されている可能性があります。

  • ビルドロジックに課題がある場合は、TeamCity 関連の課題(つまり、TeamCity がない同じ環境では再現しない)であることを確認し、調査の詳細を含めます。

  • ビルド手順の課題を報告するときは、同じ環境のエージェントマシンで TeamCity を使用せずに課題を再現し、結果をお知らせください。

  • 特定のビルドが影響を受ける場合は、完全なビルドログを含めます(ビルド結果のビルドログタブから専用リンクを介してダウンロードされます)。

  • ログ内の機密データを置換またはマスキングする場合、使用される置換パターンに注意してください。

  • ウイルス対策ソフトウェアがインストールされている場合や、TeamCity サーバーの前にネットワークプロキシまたはリバースプロキシがある場合は、この情報をリクエストに含めてください。

  • インストールされているバンドルされていないプラグインをリストします。

  • TeamCity データディレクトリまたはデータベースの以前の変更に注意してください。

  • テキストデータの大部分(10 KB 以上)をメールテキストに含めないでください。ファイルに添付してください。

投稿については次のガイドラインを考慮してください :

  • 既に報告された課題に関する新しい詳細を投稿する場合、新しいものを作成する代わりに、トピックに関する以前の投稿を更新します。ただし、重複したトピックを作成する必要がある場合は、作成または発見した同じトピックに関する以前の投稿をすべてメモしてください。

  • 最も重要な課題を最初に、提出ごとに 1 つの課題を投稿してください。複数の提出を行う場合、それらが関連している場合、他の課題をメモします。

収集して当社に送信する一般的なケースと特定の情報については、以下のセクションを確認してください。

スローネス、ハンギング、低パフォーマンス

TeamCity の速度が予想よりも遅い場合は、以下の注意事項を使用して、遅いプロセスを見つけ、プロセスが TeamCity のものである場合に関連するすべての詳細を送信してください。

どのプロセスが遅いかを判断する

遅い TeamCity Web UI 応答、変更プロセスの確認、サーバー側ソースのチェックアウト、長いクリーンアップ時間、またはその他の遅いサーバーアクティビティが発生する場合、ターゲットは TeamCity サーバーがインストールされているマシンである必要があります。
課題が単一のビルドにのみ関連している場合は、ビルドを実行している TeamCity エージェントマシンとサーバーを調査する必要があります。

システムリソース(CPU、メモリ、IO)の負荷を調査します。負荷が高い場合は、それが原因のプロセスを特定します。TeamCity 関連のプロセスでない場合は、TeamCity スコープ外のアドレス指定が必要になる場合があります。また、ウイルス対策ソフトウェア、メンテナンス時間などの一般的な速度低下の理由も確認してください。

CPU / IO をロードしているのが TeamCity サーバーであるか、実質的な CPU / IO 負荷がなく、TeamCity を除いてすべてが正常に実行される場合、これをさらに調査する必要があります。

マシンで矛盾するソフトウェアのようなアンチウイルスが実行されているかどうかを確認し、無効化 / アンインストールします。

TeamCity が使用するデータベースと TeamCity データディレクトリのファイルストレージにパフォーマンスの課題がないことを確認してください。

TeamCity を大量にインストールしている場合は、最初のステップとしてメモリ設定を確認してください。

データを収集する

スロー操作中に、5-10 秒間隔で、スロープロセスのスレッドダンプをいくつか取得します(アプローチを行うスレッドダンプについては以下を参照)。速度が低下し続ける場合は、スレッドダンプをさらに数回(たとえば、数分以内に 3 〜 5)取り、プロセスがまだ遅い間にしばらく(たとえば、10 分)後に繰り返します。

そして、送信(英語)私たちのスレッドダンプとフルサーバー(またはエージェント)に伴う課題の詳細な説明ログの課題をカバーします。何らかの理由で望ましくない場合を除いて、推奨される方法は、課題を課題追跡(英語)システムに提出し、サポートメールで通知することです。CPU / IO の負荷情報、特に遅いものとそうでないもの、影響を受ける URL、目に見える影響など、調査に関連するすべての詳細を含めてください。大量のデータについては、ファイルアップロードサービスを使用してアーカイブを共有してください。

サーバースレッドダンプ

サーバーでの操作が遅い場合は、低速の時間全体に分散したサーバースレッドダンプ(10 以上)のセットを取得します。TeamCity は、非常に遅い操作でスレッドダンプを自動的に保存するため、logs/threadDumps-<date> ディレクトリにすでにいくつかが保存されている場合があります。最近のすべての日付について、サーバーの <TeamCity Home>/logs/threadDumps-<date> ディレクトリのコンテンツ全体のアーカイブを送信することをお勧めします。

ハングがローカルであり、TeamCity 管理ページを開くことができる場合は、Web UI から TeamCity サーバーのスレッドダンプを取得することをお勧めします。管理 | サーバー管理 | 診断ページに移動し、スレッドダンプの保存ボタンをクリックしてダンプを <TeamCity Home>/logs/threadDumps-<date> ディレクトリに保存します。(後で「サーバーログ」からファイルをダウンロードできます)。サーバーが完全に起動しているのに WebUI が応答しない場合は、TeamCity サーバーの実際の URL を使用して直接 URL(英語) を試してください。

UI にアクセスできない場合(またはサーバーがまだ完全に起動していない場合)、以下で説明する方法を使用して、サーバースレッドダンプを手動で取得できます。

teamcity.diagnostics.requestTime.threshold.ms=30000 内部プロパティを調整してタイムアウトを変更することもできます。その後、タイムアウトよりも時間がかかるユーザー発信の Web 要求があるたびに、TeamCity ログの threadDumps-<date> ディレクトリにスレッドダンプが自動的に作成されます。

サーバーでの CPU プロファイリングデータの収集

サーバーのパフォーマンスが低下し、TeamCity サーバープロセスが大きな CPU 負荷を生成している場合は、CPU プロファイリングのスナップショットを作成し、実行内容とシステムセットアップの詳細な説明を添えて送信してください。サーバープロファイリングプラグイン(英語)をインストールし、プラグインページの指示に従うことで、CPU プロファイリングとメモリスナップショットを取得できます。

CPU プロファイリングから最高の結果を得るためのヒントを次に示します。

  • サーバーを起動した後、しばらく待って「ウォームアップ」します。これには、TeamCity が保管するデータ量に応じて 5 〜 20 分かかります。

  • サーバーで CPU 使用率の増加が見つかった場合は、どのアクションが負荷の原因であるかを示してください。

  • CPU プロファイリングを開始し、アクションを数回繰り返します(5 - 10)。

  • スナップショットをキャプチャーします。

  • スナップショットをアーカイブして、CPU 負荷の原因となるアクションの説明を含めて、スナップショットを送信します。

エージェントスレッドダンプ

Web UI からエージェントスレッドダンプを取得することをお勧めします。エージェントページのエージェント概要タブに移動し、エージェントのスレッドをダンプするアクションを使用します。

UI にアクセスできない場合は、以下で説明するアプローチを使用して、ダンプスレッドを手動で取得できます。TeamCity エージェントは、ランチャーとエージェント自体の 2 つの java プロセスで構成されていることに注意してください。エージェントはランチャーによってトリガーされます。通常は、ランチャープロセスではなく、エージェント(ネストされた)プロセスに関心があります。

スレッドダンプの取得

これらは、TeamCity Web UI からスレッドダンプを取得できない場合に役立ちます。

スレッドダンプを取得するには:

Windows の下

いくつかのオプションがあります:

  • サーバーがコンソールから実行されている場合にサーバースレッドダンプを取得するには、コンソールウィンドウで Ctrl+Break(一部のキーボードでは Ctrl + Pause)を押します(コンソールはランチャープロセスに属しているため、エージェントでは機能しません)。サーバーがサービスとして実行されている場合は、サービスで構成されているのと同じ用途でログインし、<TeamCity server home>\bin\teamcity-server.bat run コマンドを実行して、コンソールから実行してみてください。別のアプローチは、TeamCity サーバープロセスのプロセス ID を把握することです(最上位の "java" プロセスは、コマンドラインの最後に "org.apache.catalina.startup。Bootstrap start" を持ち、次のアプローチを使用します) :

  • プロセスが使用する Java インストールの bin ディレクトリで jstack <pid_of_java_process> を実行します(Java ホームはプロセスコマンドラインで検索できます。インストールに jstack ユーティリティがない場合は、java -version コマンドで java バージョンを取得する必要があります。同じバージョンの完全な JDK をダウンロードし、「jstack」ユーティリティフォームを使用します)。また、コマンドに -F フラグを指定する必要がある場合があります。

  • TeamCity にバンドルされたエージェントスレッドダンプツールを使用します(エージェントのプラグインにあります)。コマンドを実行します:

<TeamCity agent>\plugins\stacktracesPlugin\bin\x86\JetBrains.TeamCity.Injector.exe <pid_of_java_process>

ハングしているプロセスがサービスとして実行されている場合、スレッドダンプツールは、(管理者として実行を使用して)管理者特権でコンソールから実行する必要があることに注意してください。サービスがシステムアカウントで実行されている場合は、 PsExec.exe (英語) -s <path to the tool>\<tool> <options> を介してスレッドダンプツールを起動する必要がある場合もあります。サービスを通常のユーザーで実行する場合、ツールの呼び出しを " でラップします。PsExec.exe -u <user> -p <password> <path to the tool>\<tool> <options> も役立つかもしれません。

これらのいずれもサービスとして実行されているサーバーで機能しない場合は、サービスとしてではなくコンソールからサーバーを実行してみてください。この方法で、最初の(Ctrl + Break)オプションを使用できます。

Linux の下

  • jstack <pid_of_java_process> (プロセスで使用される Java インストールから jstack を使用)または kill -3 <pid_of_java_process> を実行します。後者の場合、出力は <TeamCity Home>logs/catalina.out または <TeamCity agent home>/logs/error.log に表示されます。

上記のサーバーのパフォーマンスセクションも参照してください。

データベース関連のスローダウン

サーバーが遅い場合、問題がデータベース操作によって引き起こされているかどうかを確認します。データベース固有のツールを使用することをお勧めします。

debug-sql サーバーロギングプリセットを使用することもできます。有効にすると、1 秒以上かかるすべてのクエリが teamcity-sql.log ファイルに記録されます。時間は、teamcity.sqlLog.slowQuery.threshold 内部プロパティを設定することで変更できます。値はミリ秒単位で設定する必要があり、デフォルトでは 1000 です。

MySQL

サーバースレッドダンプとともに、MySQL コンソールで実行された show processlist; SQL コマンドの出力を必ず添付してください。スレッドダンプの場合と同様に、遅延が発生した場合にコマンドを数回実行して出力を送信するのは理にかなっています。また、my.ini の変更で実行された長いクエリのログを保持するように MySQL をセットアップできます。

[mysqld] ... log-slow-queries long_query_time=15

ログは分析のために当社に送信することもできます。

メモリ不足の問題

TeamCity がメモリを大量に消費する問題、またはログで「OutOfMemoryError」/「Java ヒープスペース」エラーが発生する場合は、次の手順を実行します。

  • エラーが発生したプロセス(実際の構築プロセス、TeamCity サーバー、または TeamCity エージェント)を判別します。TeamCity Web UI の管理 | サーバー管理 | 診断ページのチャートを使用して、TeamCity によるメモリと CPU の使用量を追跡できます。

  • サーバーに問題がある場合は、実稼働環境でサーバーを使用するためのデフォルト設定からメモリ設定を増やしたことを確認してください(セクションを参照)。

  • ビルドプロセスが原因である場合は、ビルドランナーで「JVM コマンドラインパラメーター」設定を設定します。 -Xmx JVM オプションの値を増やします(例: -Xmx1200m)。Java インスペクションビルドでは、-Xmx 値を増やす必要があることに注意してください。

  • TeamCity サーバーが原因であり、メモリサイズを増やしても解決しない場合は、ケースを報告して調査してください。サーバーはメモリ消費量の高い間はこのために、説明したように、いくつかのサーバースレッドダンプを取るでメモリダンプを取得し、(下記参照)と threadDumps-* サブディレクトリを含むすべてのサーバーログ、結果をアーカイブし、送信するために私たちにさらなる分析。ダンプを取得する前に、-Xmx 設定が 8Gb 未満であることを確認してください。
    • メモリダンプ(hprof ファイル)が自動的に作成される場合、java_xxx.hprof ファイルはプロセス起動ディレクトリ(<TeamCity ホーム > / bin または <TeamCity エージェントホーム > / bin`)に作成されます。

    • サーバーの場合、メモリ使用量がピークに達したときにメモリダンプを手動で取得することもできます。TeamCity Web UI の管理 | サーバー管理 | 診断ページに移動し、ダンプメモリスナップショットをクリックします。

    • メモリダンプを手動で取得する別のアプローチは、プロセスで使用される Java と同じバージョンの完全な JVM インストールの jmap 標準 JVM コマンドラインユーティリティを使用することです。コマンドラインの例は次のとおりです。

      jmap -dump:file=<file_on_disk_to_save_dump_into>.hprof <pid_of_the_process>

サーバーおよびエージェントの JVM オプションを変更する方法を参照してください。

「開いているファイルが多すぎます」エラー

  1. 発生するコンピューターを判別する

  2. 多くのファイルとファイルリストを開いたプロセスを特定する (Linux では lsof を使用し、Windows ではハンドル(英語)または TCPView(英語) を使用してソケットを一覧表示できます。)

  3. 数が数千未満の場合は、OS とファイルハンドルのプロセス制限(Linux では ulimit -n を使用)を確認し、必要に応じて増やします。プロセスごとのデフォルトの Linux1024 ハンドルは、TeamCity のようなサーバーアプリケーションには小さすぎることに注意してください。番号を少なくとも 16000 に増やします。OS にはグローバルおよびセッションごとの制限の設定が異なるため、変更後は実際のプロセス制限を確認してください (例:投稿(英語)を参照)

ファイルの数が多く、疑わしいと思われ、ロックプロセスが TeamCity の場合(TeamCity エージェントまたは他の Web アプリケーションが実行されていないサーバー)、引き続き課題が発生している間に、開いているハンドルのリストを数回取得し、数分間隔で関連する詳細とともに調査のために結果を送信します。

ほとんどの場合、アプリケーションの正常な機能を回復するには、調査後にエラーでマシンを再起動する必要があることに注意してください。

エージェントはサーバーに接続しません

よくある問題を参照してください

イベントのログ

TeamCity サーバーとエージェントは、課題の調査に使用できるログを作成します。

詳細については、対応するセクションを参照してください。

バージョン管理デバッグログ

ほとんどの VCS 操作は TeamCity サーバーで行われますが、エージェント側のチェックアウトを使用している場合、ビルドエージェントで VCS チェックアウトが行われます。

エージェントとサーバーの場合、<TeamCity Home>/conf/teamcity-server-log4j.xml または <BuildAgent home>/conf/teamcity-agent-log4j.xml ファイルの Log4j 構成を手動で変更して、次のフラグメントを含めることができます。

<category name="jetbrains.buildServer.VCS" additivity="false">     <appender-ref ref="ROLL.VCS"/>     <appender-ref ref="CONSOLE-ERROR"/>     <priority value="DEBUG"/> </category>   <category name="jetbrains.buildServer.buildTriggers.vcs" additivity="false">     <appender-ref ref="ROLL.VCS"/>     <appender-ref ref="CONSOLE-ERROR"/>     <priority value="DEBUG"/> </category>

<appender name="ROLL.VCS"> ノードを更新して、保存するファイルの数を増やしてください。

<param name="maxBackupIndex" value="30"/>

特定のバージョン管理に個別のログオプションがある場合は、以下で説明します。

Subversion デバッグロギング

エージェント側のロギングには、代替の手動アプローチも必要です。

説明したようにまず、一般的な VCS のデバッグログを有効に上記の。

サーバーおよびエージェント(エージェント側のチェックアウトが使用されている場合)上の Log4j 構成ファイルの SVN 関連部分( SVN.LOG アペンダーおよび javasvn.output カテゴリ)のコメントを外します。ログは logs/teamcity-svn.log ファイルに保存されます。汎用 VCS ログも logs/teamcity-vcs.log から取得する必要があります

ClearCase

<TeamCity Home>/conf/teamcity-server-log4j.xml ファイルの Clearcase 関連の行のコメントを外します。ログは logs/teamcity-clearcase.log ディレクトリに保存されます。

パッチ適用の問題

サーバー側のチェックアウトを使用する場合、サーバーからエージェントに渡される「パッチ」は次の方法で取得できます。

  • プロパティ system.agent.save.patch=true をビルド構成に追加します。

  • ビルドをトリガーします。ビルドログとエージェントログには、「パッチはファイル ${file.name} に保存されます」という行が含まれます。ファイルを取得し、問題の説明を提供します。

VCS トリガーデバッグロギング

特定のビルド構成で VCS トリガーのデバッグログを有効にするには:

  1. デフォルトのロギングプリセットファイル <TeamCity Home>/conf/teamcity-server-log4j.xml を取得し、<TeamCity Data Directory>/config/_logging/ ディレクトリに別の名前で保存します。

  2. 結果のファイルを次のように変更します。

    • 新しいトリガーを追加して、VCS トリガー関連イベントを別のファイルに記録します。

    <appender name="ROLL.VCS.TRIGGER" class="jetbrains.buildServer.util.TCRollingFileAppender"> <param name="file" value="${teamcity_logs}/teamcity-vcs-trigger.log"/> <param name="maxBackupIndex" value="20"/> <layout class="org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="[%d] %6p [%15.15t] - %30.30c - %m%n"/> </layout> </appender>
    • 次のように、jetbrains.buildServer.buildTriggers.vcs.AllBranchesVcsTrigger_<build configuration id> という名前の新しいカテゴリを追加します。

    <category name="jetbrains.buildServer.buildTriggers.vcs.AllBranchesVcsTrigger_MyBuildConfigurationId"> <priority value="DEBUG"/> <appender-ref ref="ROLL.VCS.TRIGGER"/> </category>

    注:上記の例では、MyBuildConfigurationId は、デバッグする VCS トリガーを含むビルド構成の ID です。

  3. 管理 | 診断ページのログプリセットを新しく作成したプリセットファイルに切り替えます。

サーバーの再起動は必要ありません。構成が正しい場合、TeamCity は teamcity-vcs-trigger.log ログファイルを数分で作成します。ファイルには、選択した構成のみに関連するデバッグログが含まれます。

.NET ランナーのロギング

.NET 関連のランナーのプロセス起動の課題を調査するには、以下の説明に従ってデバッグを有効にします。その後、詳細情報がビルドログに出力されます。デバッグログを長時間保持せず、調査後に設定を元に戻すことをお勧めします。

ロギングを有効にする別の方法は次のとおりです。ビルド構成またはエージェントに teamcity.agent.dotnet.debug=true 構成パラメーターを追加して、ビルドを実行します。

  1. <agent home>/plugins/dotnetPlugin/bin フォルダーを開きます。

  2. teamcity-log4net.xml のバックアップコピーを作成する

  3. teamcity-log4net.xmlteamcity-log4net-debug.xml のコンテンツに置き換えます

リモート実行の問題

IDE からリモート実行時にサーバーに送信される変更は、サーバー .BuildServer/system/changes ディレクトリから取得できます。変更に対応する <change_number>.changes ファイルを見つけます(利用可能な最新の番号を選択するか、Web UI から変更の URL を推測できます)。ファイルには、バイナリ形式のパッチが含まれています。問題の説明とともに送信してください。

IntelliJ IDEA / プラットフォームベースの IDE へのログイン

IntelliJ プラットフォームベースの IDE プラグインのデバッグロギングを有効にするには、<IDE home>/bin/log.xml ファイルの Log4j 構成に次のフラグメントを含めます。

<appender name="TC-FILE" class="org.apache.log4j.RollingFileAppender">   <param name="MaxFileSize" value="10Mb"/>   <param name="MaxBackupIndex" value="10"/>   <param name="file" value="$LOG_DIR$/idea-teamcity.log"/>   <layout class="org.apache.log4j.PatternLayout">     <param name="ConversionPattern" value="%d [%7r] %6p - %30.30c - %m \n"/>   </layout> </appender>   <appender name="TC-XMLRPC-FILE" class="org.apache.log4j.RollingFileAppender">   <param name="MaxFileSize" value="10Mb"/>   <param name="MaxBackupIndex" value="10"/>   <param name="file" value="$LOG_DIR$/idea-teamcity-xmlrpc.log"/>   <layout class="org.apache.log4j.PatternLayout">     <param name="ConversionPattern" value="%d [%7r] %6p - %30.30c - %m \n"/>   </layout> </appender>   <category name="jetbrains.buildServer.XMLRPC" additivity="false">   <priority value="DEBUG"/>   <appender-ref ref="TC-XMLRPC-FILE"/> </category>   <category name="jetbrains.buildServer" additivity="false">   <priority value="DEBUG"/>   <appender-ref ref="TC-FILE"/> </category>

このファイルを変更した後、IDE を再起動します。TeamCity プラグインのデバッグログは idea-teamcity\* ファイルに保存され、IDE 設定のログディレクトリ(<IDE settings/Data Directory>/system/log ディレクトリ)に表示されます。

IDE 機能ログで開く

(IntelliJ IDEA および Eclipse に適用可能)IDE を起動する前に、次の JVM オプションを追加します。
-Dteamcity.activation.debug=true

IDE で開く機能に関連するログが IDE コンソールに表示されます。

リモート実行に適したビルド構成が見つかりません

まず、IDEA の VCS 設定が TeamCity の VCS 設定に対応していることを確認します。そうでない場合は、変更して問題を解決する必要があります。

次に、IDEA プロジェクトに適したビルド構成にサーバー側の VCS チェックアウトモードまたはエージェント側のチェックアウトがあり、手動 VCS チェックアウトモードではないことを確認します(TeamCity はそれを適用する必要があるため、手動チェックアウトモードでビルドに個人用パッチを適用することはできません) VCS チェックアウトの補完後にパッチを適用しますが、実行時間を認識または管理しません)。

設定が同じで、手動チェックアウトモードを使用しないが、問題がある場合は、次を実行します。

  • IDEA VCS 設定と TeamCity VCS 設定を提供してください (IDEA プロジェクトに適していると予想されるビルド構成)

  • TeamCity IntelliJ プラグインのデバッグログを有効にする ( 上記参照)

  • TeamCity サーバーのデバッグログを有効にする ( 上記参照)

  • TeamCity IntelliJ プラグインで、リモート実行ビルドを開始してみてください

  • TeamCity IntelliJ プラグインおよび TeamCity サーバーからのデバッグログを提供してください。

TeamCity Eclipse プラグインへのログイン

プラグインのトレースを有効にするには、-debug <filename> コマンドラインパラメーターを使用して Eclipse IDE を実行します。引数の <filename> 部分は、キーと値のペアを含むプロパティファイルである必要があります。各プロパティの名前はプラグインモジュールに対応し、値は true (デバッグを有効にする)または false のいずれかです。最も一般的なトレースオプションを有効にする例を次に示します。

jetbrains.teamcity.core/debug = true jetbrains.teamcity.core/debug/communications = false jetbrains.teamcity.core/debug/ui = true jetbrains.teamcity.core/debug/vcs = true jetbrains.teamcity.core/debug/vcs/detail = true jetbrains.teamcity.core/debug/parser = true jetbrains.teamcity.core/debug/platform = true jetbrains.teamcity.core/debug/teamcity = true jetbrains.teamcity.core/perfomance/vcs = true jetbrains.teamcity.core/perfomance/teamcity = true

Eclipse デバッグモードプラグインに関する情報の収集(英語)および組み込み Eclipse ヘルプの詳細を参照してください。

TeamCity Visual Studio アドインの課題

TeamCity アドインロギング

TeamCity Visual Studio アドインからログをキャプチャーするには:

  1. Visual Studio インストールディレクトリを見つけます (以下の例では、c:\Program Files (x86)\Microsoft Visual Studio\2017\Common7\IDE )

  2. ReSharper 関連のコマンドライン引数を使用して、コマンドラインから Microsoft Visual Studio 実行可能ファイル(INSTALLATION_DIRECTORY\Common7\IDE\devenv.exe)を実行します。

    • ReSharper Ultimate の一部としての TeamCity VS アドインの場合、/ReSharper.LogFile <PATH_TO_FILE> および /ReSharper.LogLevel <Normal|Verbose|Trace> スイッチを使用します

      c:\Program Files (x86)\Microsoft Visual Studio\2017\Common7\IDE>devenv.exe /ReSharper.LogFile C:\Users\jetbrains\Desktop\vs.log /ReSharper.LogLevel Verbose
    • TeamCity VS アドインのレガシーバージョンの場合、/TeamCity.LogFile <PATH_TO_FILE> および /TeamCity.LogLevel <Normal|Verbose|Trace> スイッチを使用します

Visual Studio ロギング

一般的な Visual Studio のトラブルシューティングを行うには、/ Log (英語) コマンドラインスイッチを使用して Microsoft Visual Studio 実行可能ファイル INSTALLATION_DIRECTORY\Common7\IDE\devenv.exe を実行し、結果のログファイルを送信します。

dotCover の課題

JetBrains dotCover によって生成された追加のログを収集するには、teamcity.agent.dotCover.log 構成パラメーターをビルド構成に追加し、エージェント上の空のディレクトリへのパスを使用します。すべての dotCover ログファイルがそこに配置され、TeamCity は圧縮されたログを非表示のビルドアーティファクト .teamcity/.NETCoverage/dotCoverLogs.zip として公開します。

JVM クラッシュ

TeamCity サーバーまたはエージェントプロセスが明確な理由なしに予期せず終了するというまれなケースでは、これは Java ランタイムのクラッシュが原因である可能性があります。これが発生した場合、JVM はプロセスの作業ディレクトリに hs_err_pid*.log という名前のファイルを定期的に作成します。作業ディレクトリは通常、<TeamCity server> または agent home >/bin です。
Windows では、サービスとして実行している場合、C:\Windows\SysWOW64 のようなものにすることができます。名前に「hs_err_pid」が含まれている最近のファイルをディスクで検索することもできます。このドキュメント(英語)の関連する致命的なエラーログのセクションも参照してください。

調査のためにこのファイルを送信し、サーバー(またはエージェント)の JVM を利用可能な最新バージョンに更新することを検討してください。

「Java ランタイム環境を続行するにはメモリが不足しています。ネイティブメモリ割り当て(malloc)の割り当てに失敗しました ...」というクラッシュメッセージまたはクラッシュレポートファイルが表示された場合は、64 ビット JVM に切り替えるを確認するか、-Xmx 設定を減らしてください 1024m 以下では、メモリ構成セクションの詳細を参照してください。

ビルドログの課題

ビルドログに関連する課題を調査する際、TeamCity に保存されている生のバイナリビルドログが必要になる場合があります。ビルドログビルドのタブから Web UI を介してダウンロードできます。「詳細」ログの詳細を選択し、右上の「生メッセージファイル」リンクを使用します。

IntelliJ IDEA インスペクション

TeamCity ビルドのインスペクション結果は、IntelliJ IDEA でのローカル実行のインスペクションと一致しない場合があります。

インスペクションの課題を調査するには、次の手順を実行します。

  1. system.teamcity.dont.delete.temp.result.dir=true構成パラメーターに追加します

  2. %system.teamcity.build.tempDir%/inspection*result/** => inspections-reports-data-%build.number%.zip ルールをアーティファクトパスに追加します

  3. %system.teamcity.build.tempDir%/idea-logs/** => inspections-reports-idea-logs-%build.number%.zip ルールをアーティファクトパスに追加します

  4. ランナーの JVM コマンドラインパラメーターフィールドに -Didea.log.path=%system.teamcity.build.tempDir%/idea-logs/ を追加します。

  5. 新しいビルドを実行します。

  6. inspections-reports-*.zip ファイルを送ってください。

大きなデータアーカイブのアップロード

サイズが 10MB 未満のファイルは、トラッカーの課題(英語)に直接添付できます(添付ファイルを公開したくない場合は、添付ファイルの表示を「teamcity-developers」ユーザーグループのみに制限してください)。
小さなファイル(最大 2 MB)をメール(teamcity-support@jetbrains.com)またはオンラインフォーム(英語)(最大 20 MB)で送信することもできます。添付する前に、TeamCity のバージョンと環境を記載し、ファイルをアーカイブすることを忘れないでください。

大きなファイルは https://uploads.jetbrains.com/ (英語) 経由でアップロードできます。アップロード後に正確なファイル名をお知らせください。

大きなファイルを一度にアップロードできない場合は、ファイルを部分に分割して、個別にアップロードしてみてください。