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 ファイルで構成されているとおり)を確認し、エージェントサーバー UI セクションのタブを確認します。

  • エージェントは接続中です - エージェントはビルドを実行する準備ができています

  • エージェントは切断されています - エージェントはサーバーに接続されていましたが、切断されました。表内の「非活動理由」を確認してください。理由が「エージェントの登録が解除されている(アップグレードされる)」であれば、さらに数分待ちます。

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

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

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

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

  • 関連するメッセージ / エラーがないかエージェントログteamcity-agent.log , launcher.log , upgrade.log)を確認してください。

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

ログでエージェントのアップグレードの遅延の原因が見つからない場合は、Google に連絡して(英語)、エージェントとサーバーの完全なログを提出してください。エージェントマシン上のエージェントプロセス(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. max_allowed_packet 構成変数(英語)の値を確認するには、my.cnf / my.ini を調べるか、または

    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 でもかまいません。

これは TeamCity 6.0 以上に適用されます。

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

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

  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 バイトです

MySQL データベースの文字セットを確認してください。 utf8 文字セットを使用することをお勧めします。

データベースで utf8mb4 文字セット(MySQL 5.5 以降で利用可能)を使用している場合は、TeamCity 2017.2.1 + を実行するために次の InnoDB 設定オプション( my.cnf または my.ini[mysqld] セクションの下)を設定します。

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

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

  • バラクーダファイル形式を有効にする innodb_file_per_table=1 上記のパラメーターには、次のデフォルト値があります。

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 を実行します。実行はサーバーマシンで実行され、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 フィードに関する問題

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

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

以前のバージョンについては、このセクション(英語)を参照してください。

トップに戻る

.Net 関連の TeamCity ツールに関する問題

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

TeamCity 9.0 以降にアップグレードした後、TeamCity エージェントにインストールされたバージョン 4.0 より下の .NET フレームワークは、マイクロソフトによって課されたコードアクセスセキュリティ(CAS)ポリシーのために .Net 関連 TeamCity ツールのパフォーマンス課題を引き起こすかもしれません。

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

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

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

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

  2. または、TeamCity エージェントの .NET フレームワークをバージョン 4.0 以上にアップグレードします。詳細はマイクロソフトのドキュメント(英語)にあります。

トップに戻る

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

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

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

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

トップに戻る

最終更新日 :