TeamCity 2020.2 ヘルプ

よくある問題

ほとんどのユーザーの問題は、次のトピックに関連しています。問題を報告する前に、これらのヘルプページのいずれかに解決策がすでに含まれているかどうかを確認してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 同じコンソールウィンドウで cd から <TeamCity エージェントホーム > / 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.loglauncher.logupgrade.log)を確認してください。

  • エージェント名または IP についてメンションしているメッセージ / エラーがないか、サーバーログteamcity-server.log)を確認してください。

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

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

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

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

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

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

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

データベース関連の問題

内部(HSQLDB)データベースでの「メモリ不足」エラー

TeamCity サーバーの起動中に、「スクリプトファイル行のエラー: ... メモリ不足」「java.sql.SQLException: メモリ不足」などのエラーが発生した場合は、次の手順を実行します。

  • サーバーメモリを増やしてみてください。これが役に立たない場合は、おそらくこれは、内部データベースの破損が発生したことを意味します。HSQLDB のドキュメントに基づくメモ(英語)を使用して、この破損に対処することができます。

これは手動でデータベースを復元する方法です。

ただし、データベースが自動的に回復しない場合は、手動で修正できる可能性はほとんどありません。

内部(HSQL)データベースは本番環境で使用するには十分に安定していないため、TeamCity の非評価用には外部データベースを使用することを強くお勧めします。
データベースの破損が発生した場合は、最後の適切なバックアップを復元するか、ビルド履歴とユーザーを削除できますが、設定は保持されます。外部データベースへの移行を参照してください。

トランザクションログがいっぱいです

このエラーは MS SQL または Sybase データベースで発生する可能性があります。この場合、TeamCity データベースのトランザクションログを増やすことをお勧めします。システム内のビルドエージェントの数およびすべてのエージェントが毎日報告するテストの数に応じて、ログサイズは 1 - 16 GB になります。

テーブル 'table_name' がいっぱいです

このエラーは MySQL データベースで発生する可能性があります。このエラーは、データベースファイルが配置されているディスクまたは一時ディレクトリのいずれかで、データベースの空き領域が不足していることを示しています。

表領域の... セグメント... を拡張できません...

このエラーは Oracle データベースで発生する可能性があります。このエラーは、データベースのディスク上のスペースが不足しているか、指定されたクォータが不足しているため、Oracle がテーブルまたはインデックス用のスペースをこれ以上獲得できなかったことを示しています。

MS SQL Server で NOCOUNT が有効になっています

teamcity-server.log は、MS SQL データベースサーバーでサポートされていない NOCOUNT オプションが有効になっていることを報告します。設定を無効にするには、DBA に連絡してください。

MySQL JDBC ドライバエラー: PacketTooBigException

ER_NET_PACKET_TOO_LARGE(英語) エラー(PacketTooBigException/ クエリのパケットが大きすぎる)は、サーバー側の max_allowed_packet 構成変数(英語)が低い値に設定されているか、デフォルト値のままになっていることが原因です。

変数は MySQL 通信バッファの最大サイズを制御します。4MB は MySQL ビルド 5.6 の Windows ビルド用のデフォルトですが、人気のある Linux ディストリビューション(Debian や Fedora Core など)では、i686 アーキテクチャと amd64 アーキテクチャの両方でこの変数のデフォルトは 16MB です。

  1. my.cnf / my.ini を調べるか、またはを介して、max_allowed_packet 構成変数(英語)の値を確認します。

    mysql> show variables like 'max_allowed_packet';
  2. my.cnf または my.inimax_allowed_packet 構成変数(英語)の値を増やす(または明示的に設定する):

    [mysqld] max_allowed_packet=16M

データベースの文字セット / 照合順序関連の問題

文字セット / 照合順序の不一致

TeamCity は、文字セット / 照合順序の不一致エラーを報告します。データベーステーブル / 列には、データベーススキーマのデフォルトの文字セットまたは照合順序と異なる文字セットまたは照合順序があります。TeamCity が一部の varchar フィールドに Unicode 文字セットを適用するため、データベースのデフォルトとして Unicode 以外の文字セットを使用している場合は、このメッセージが表示されることがあります。データベースが私たちの推奨に従って構成されていることを確認してください。

TeamCity が国別シンボルの代わりに ???? を表示

TeamCity のテキストにローカル文字(たとえば、VCS メッセージ、テスト名、ユーザー名)を許可する場合は、適切な文字セットを使用してデータベースに移行する必要があります。

バックアップからの復元時に "Unique key violations" または "Duplicates found" エラーが発生する

ソースデータベースと宛先データベースの文字セット(または照合順序)が同じではなく、宛先文字セットの濃度がソースデータベースの濃度より小さい場合、バックアップからの TeamCity サーバーの復元は "Unique key violation" または "Duplicates found" のようなエラーで失敗することがあります。

問題を解決するには、接続先データベースに適切な文字セット(および照合順序)を選択して設定します。

大文字と小文字の区別については、考えられる遷移は次のとおりです。

  • CS> CS

  • CI> CS

  • CI> CI

ただし、常に CS を使用することをお勧めします。

ソース文字セットが Unicode または UTF の場合、宛先文字セットも Unicode または UTF でなければなりません。ソース文字セットが 8 ビットの非 UTF である場合、宛先文字セットは同じでも Unicode/ UTF でもかまいません。

文字セット / 照合順序関連の問題を解決する

問題を解決するには、以下のステップを実行してください。

  1. 適切な文字セットと照合順序を使用して新しいデータベースを作成します。大文字と小文字を区別する Unicode 照合順序を使用することをお勧めします。PostgreSQL および MySQL の説明を参照してください。MySQL の場合、utf8_bin または utf8mb4_bin が推奨されます。
    文字セットの詳細については、PostgreSQL(英語)MySQL(英語)MS SQL(英語) のドキュメントも参照してください。

  2. 現在の <TeamCity データディレクトリ >/config/database.properties ファイルをコピーし、コピー内のデータベース参照を新しく作成したデータベースに変更します。

  3. TeamCity サーバーを停止します。

  4. maintainDB ツールを使用して新しいデータベースに移行します。

    maintainDB migrate [-A <path-to-data-dir>] -T <new-database-properties-file>

    データベースのサイズによっては、移行に数分から数時間かかることがあります。 maintainDB tool の詳細については、このセクションを参照してください。

  5. データベースの移行が正常に完了すると、maintainDB ツールは新しいデータベースへの参照を使用して <TeamCity データディレクトリ >/config/database.properties ファイルを更新します。ファイルが更新されたことを確認してください。ツールが自動的にファイルを作成できない場合は、ファイルを手動で編集してください。

  6. TeamCity サーバーを起動します。

MySQL の例外: 指定されたキーが長すぎます: 最大キー長は 767 バイトです

インデックスの列サイズが大きすぎます: 最大列サイズは 767 バイトです

Check if the character set of your MySQL database. It is recommended to use the utf8 character set.

If your database uses the utf8mb4 character set (available since MySQL 5.5), set the following InnoDB configuration options (under [mysqld] section in my.cnf or my.ini ) to run:

  • 767 バイト(最大 3072 バイト)より長いインデックスキープレフィックスの innodb_large_prefix=1 は、DYNAMIC 行形式(MySQL 5.7.7 で非推奨)を使用する InnoDB テーブルで許可されます。

  • DYNAMIC 行フォーマットを有効にするための innodb_file_format=Barracuda

  • innodb_file_per_table=1 to enable the Barracuda file format

The parameters above have the following default values:

MySQL 5.5

MySQL 5.6

MySQL 5.7

MariaDB 5.5

MariaDB 10.0

MariaDB 10.1

MariaDB 10.2

innodb_large_prefix

0

0

1

0

0

0

1

innodb_file_format

Antelope

Antelope

Barracuda

Antelope

Antelope

Antelope

Barracuda

innodb_file_per_table

0

1

1

1

1

1

1

データベースサーバーのバージョンに応じて、以下の設定変更を行う必要があります。

MySQL 5.5:

  • innodb_large_prefix=1
  • innodb_file_format=Barracuda
  • innodb_file_per_table=1

MySQL 5.6 および MariaDB(5.5 から 10.1 まで):

  • innodb_file_format=Barracuda
  • innodb_file_per_table=1

MySQL 5.7+ と MariaDB 10.2+ の場合はデフォルトを使用します。変更は必要ありません。

MySQL の「不正な文字列値」エラー

  1. MySQL で utf8mb4 文字セットを使用し、my.cnf[mysqld] セクションにある次のオプションを使用して、デフォルトで utf8mb4 を使用するように MySQL サーバーを設定します。

    character_set_server = utf8mb4
    collation_server = utf8mb4_bin

  2. my.cnf への変更を有効にするために MySQL を再起動してください。

MS SQL データベースで「このドライバは統合認証用に構成されていません」エラー

TeamCity のインストール中に、Windows 統合セキュリティを使用して MS SQL データベースを接続および作成するときに、「SQL エラー: データソースからの接続を確立しています。このドライバは統合認証用に構成されていません」というエラーが発生することがあります。

この問題の最も一般的な理由は、sqljdbc_auth.dll MS SQL 共有ライブラリと TeamCity によって使用される JRE の異なるビット性です。

問題を解決するには、次の手順に従います。

  1. 必ず MS SQL ネイティブドライバ(マイクロソフトダウンロードセンター(英語)からダウンロード可能)を使用してください。

  2. 正しい JRE bitness を使用してください。sqljdbc_auth.dll MS SQL 共有ライブラリと同じ bitness で Java を使用して TeamCity を実行していることを確認してください。デフォルトでは、TeamCity は 32 ビット Java を使用します。ただし、32 ビット版と 64 ビット版の両方の Java バージョンを使用できます

必要な JRE で TeamCity を実行するには、次のいずれかを実行します。* TEAMCITY_JRE 環境変数を設定するか、または * TeamCity にバンドルされている JRE を <TeamCity ホーム > \ jre から削除して JAVA_HOME を設定します。

この関連する外部投稿(英語)も参照してください。

プロトコル違反エラー (Oracle のみ)

このエラーは、Oracle JDBC ドライバが Oracle サーバーと互換性がない場合に発生する可能性があります。例: Oracle JDBC ドライバーのバージョン 11.1 は、Oracle サーバーのバージョン 10.2 と互換性がありません。

この問題を解決するには、Oracle サーバーのインストールから Oracle JDBC ドライバーを使用するか、Oracle サーバーと同じバージョンのドライバー(英語)ダウンロードし(英語)ます。

一般的な Maven の問題

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

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

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

Maven タブの情報を収集するため、または Maven 依存関係チェック(トリガー用)を実行するために、TeamCity は組み込み Maven を実行します。実行はサーバーマシンで実行され、エージェント側の 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 ツールの問題

起動時のパフォーマンスの問題

.NET Framework below version 4.0 installed on TeamCity agents may cause performance issues of .NET-related TeamCity tools due to Code access security (CAS) policy imposed by Microsoft.

この問題を解決するには、次のいずれかの方法を使用してください。

  1. すべてのエージェントで、マイクロソフトのドキュメント(英語)に記述されている以下の設定を machine.config ファイルに追加します。

    <configuration> <runtime> <generatePublisherEvidence enabled="false"/> </runtime> </configuration>

    この外部ブログ投稿(英語)で説明されているように machine.config ファイルを変更し、カスタムスクリプトを使用するなどして、この構成ファイルをすべてのエージェントに渡すことができます。

  2. Alternatively, upgrade .NET Framework on the TeamCity agents to version 4.0 and above. Details are available in the マイクロソフトのドキュメント(英語)

手動入力が必要なツールの使用、特に Extended Validation コード署名

TeamCity エージェント上で実行されるビルド手順の間に何らかの手動の対話を必要とするツールを使用したいと思うかもしれません。これは TeamCity 固有の問題ではないため、一般的な方法で対処する必要があります。

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

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

関連ページ:

TeamCity サーバーのインストールと設定

このページでは、新しい TeamCity サーバーのインストールについて説明します。アップグレード手順については、アップグレードを参照してください。TeamCity サーバーをインストールするには、次の手順に従います。以下の詳細に基づいて、適切な TeamCity ディストリビューション(、または Docker イメージ)を選択します。AWS スタックで TeamCity を実行することもできます。ディストリビューションをダウンロードします。ソフトウェア要件とハードウェア要件のメモ、およびプラットフォ...

パフォーマンスモニター

パフォーマンスモニターのビルド機能を使用すると、ビルドエージェントでのビルド実行中の CPU、ディスク、メモリの使用状況に関する統計を取得できます。パフォーマンスモニターは、Windows、Linux、macOS、Solaris、FreeBSD オペレーティングシステムをサポートしています。Perl を Windows 以外の使用 OS にインストールする必要があります。パフォーマンスモニターは、オペレーティングシステム全体の負荷を報告することに注意してください。同じホスト上で複数のエージェントが...

クリーンアップ

TeamCity のクリーンアップ機能により、古いビルドデータや不要なビルドデータを自動的に削除できます。サーバーのクリーンアップ構成は管理 | サーバー管理 | クリーンアップ設定で使用可能です。クリーンアップスケジュールの設定が可能で、一般的なクリーンアップ情報が表示されます。特定のプロジェクトに関連するクリーンアップルールは、プロジェクト設定 | クリーンアップ規則で構成されます。これらのルールは、どのデータをクリーンアップし、何を保存するかを定義します。これらは、プロジェクトまたはビルド...