TeamCity 2019.1ヘルプ

よくある問題

ビルドはローカルで機能しますが、失敗するか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)を確認してください。

ログにエージェントのアップグレードの遅延の原因が見つからない場合は、弊社に連絡して(英語)、エージェントとサーバーの完全なログを提供してください。エージェントマシン上のエージェントプロセス(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である場合、宛先文字セットは同じでもユニコード / UTFでもかまいません。

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

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

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

  1. 適切な文字セットと照合順序で新しいデータベースを作成します。大文字と小文字を区別するUnicode照合を使用することをお勧めします。PostgreSQLMySQLの説明を参照してください。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

  • 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フィードに関する問題

部分的なTeamCity、NuGetフィード、つまりNuGetパッケージが見つからないなどの課題が発生した場合は、TeamCity NuGetフィードのインデックスを再作成する必要があります。

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

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

トップに戻る