メインコンテンツまでスキップ
メインコンテンツまでスキップ

継続的インテグレーション (CI)

プルリクエストを提出すると、ClickHouseの継続的インテグレーション (CI) systemによってあなたのコードに対していくつかの自動チェックが実行されます。 これは、リポジトリのメンテナ（ClickHouseチームの誰か）があなたのコードを確認し、プルリクエストに can be tested ラベルを追加した後に行われます。 チェックの結果は、GitHubチェックのドキュメンテーションで説明されているように、GitHubのプルリクエストページにリストされます。 チェックに失敗した場合は、修正が必要となる場合があります。 このページでは、遭遇する可能性があるチェックの概要と、それを修正するためにできることを説明します。

チェックの失敗があなたの変更に関連していないように見える場合、一時的な失敗またはインフラの問題である可能性があります。 CIチェックを再起動するために、プルリクエストに空のコミットをプッシュしてください：

何をすべきか不明な場合は、メンテナに援助を求めてください。

マスタとのマージ​

PRがマスターにマージできるかどうかを確認します。 できない場合は Cannot fetch mergecommit というメッセージで失敗します。 このチェックを修正するには、GitHubのドキュメントに記載されているようにコンフリクトを解決するか、masterブランチをあなたのプルリクエストブランチにマージしてください。

ドキュメントチェック​

ClickHouseのドキュメントウェブサイトをビルドしようとします。 ドキュメントに何か変更を加えた場合、失敗する可能性があります。 最も考えられる理由は、ドキュメント内のいくつかのクロスリンクが間違っていることです。 チェックレポートに移動し、ERRORおよびWARNINGメッセージを探してください。

説明チェック​

プルリクエストの説明がテンプレートPULL_REQUEST_TEMPLATE.mdに準拠していることを確認します。 変更のためのチャンジログカテゴリー（例：バグ修正）を指定し、変更を説明するユーザーフレンドリーなメッセージをCHANGELOG.mdに記載する必要があります。

DockerHubへのプッシュ​

ビルドとテストに使用されるDockerイメージをビルドし、それをDockerHubにプッシュします。

マーカーチェック​

このチェックは、CIシステムがプルリクエストの処理を開始したことを意味します。 'pending'ステータスの場合、すべてのチェックがまだ開始されていないことを意味します。 すべてのチェックが開始されると、ステータスは'success'に変更されます。

スタイルチェック​

utils/check-style/check-styleバイナリを使用して、コードスタイルの簡単な正規表現ベースのチェックを実行します（ローカルで実行することもできます）。 失敗した場合は、コードスタイルガイドに従ってスタイルエラーを修正してください。

ローカルでのスタイルチェックの実行:​

ファストテスト​

通常、これはPRのために最初に実行されるチェックです。 ClickHouseをビルドし、ほとんどの無状態関数テストを実行しますが、一部を省略します。 失敗した場合、修正されるまで他のチェックは開始されません。 どのテストが失敗しているかを報告で確認し、その失敗をローカルで再現する方法については、こちらを参照してください。

ローカルでのファストテストの実行:​

ステータスページファイル​

  • runlog.out.logは、すべての他のログを含む一般的なログです。
  • test_log.txt
  • submodule_log.txtは、必要なサブモジュールのクローンおよびチェックアウトに関するメッセージを含みます。
  • stderr.log
  • stdout.log
  • clickhouse-server.log
  • clone_log.txt
  • install_log.txt
  • clickhouse-server.err.log
  • build_log.txt
  • cmake_log.txtは、C/C++およびLinuxフラグのチェックに関するメッセージを含みます。

ステータスページ列​

  • テスト名には、テストの名前が含まれており（パスなしで、例：すべての種類のテストは名前にストリップされます）。
  • テストステータス -- スキップ、成功、または_失敗_のいずれか。
  • テスト時間、秒 -- このテストでは空になります。

ビルドチェック​

さまざまな構成でClickHouseをビルドし、さらなるステップで使用します。 ビルドが失敗した場合は、それを修正する必要があります。 ビルドログにはエラーを修正するのに十分な情報が含まれていることが多いですが、ローカルで失敗を再現する必要があるかもしれません。 cmakeオプションはビルドログの中にあり、cmakeでgrepできます。 これらのオプションを使用し、一般的なビルドプロセスに従ってください。

レポート詳細​

  • コンパイラ: clang-19、オプションでターゲットプラットフォームの名前
  • ビルドタイプ: DebugまたはRelWithDebInfo（cmake）。
  • サニタイザー: none（サニタイザーなし）、address（ASan）、memory（MSan）、undefined（UBSan）、またはthread（TSan）。
  • ステータス: successまたはfail
  • ビルドログ: ビルドおよびファイルコピーのログへのリンク、ビルドが失敗した場合に便利です。
  • ビルド時間。
  • アーティファクト: ビルド成果物ファイル（XXXはサーバーバージョン、例：20.8.1.4344）。
    • clickhouse-client_XXX_amd64.deb
    • clickhouse-common-static-dbg_XXX[+asan, +msan, +ubsan, +tsan]_amd64.deb
    • clickhouse-common-staticXXX_amd64.deb
    • clickhouse-server_XXX_amd64.deb
    • clickhouse: メインのビルドバイナリ。
    • clickhouse-odbc-bridge
    • unit_tests_dbms: ClickHouseユニットテストを含むGoogleTestバイナリ。
    • performance.tar.zst: パフォーマンステスト用の特別なパッケージ。

特殊ビルドチェック​

clang-tidyを使用して静的解析およびコードスタイルチェックを実行します。レポートはビルドチェックに似ています。ビルドログ内で見つかったエラーを修正してください。

ローカルでclang-tidyを実行する:​

clang-tidyビルドをdockerで実行する便利なpackagerスクリプトがあります

無状態関数テスト​

さまざまな構成でビルドされたClickHouseバイナリに対して無状態関数テストを実行します -- リリース、デバッグ、サニタイザー付きなど。 報告書を見てどのテストが失敗しているかを確認し、その失敗をローカルで再現する方法についてはこちらを参照してください。 正しいビルド構成を使用して再現する必要があることに注意してください -- テストはAddressSanitizerの下で失敗するかもしれませんが、Debugでは成功するかもしれません。 CIビルドチェックページからバイナリをダウンロードするか、ローカルでビルドしてください。

有状態関数テスト​

有状態関数テストを実行します。 これらは無状態関数テストと同様の方法で扱います。 違いは、それらはclickstream datasetの hits と visits テーブルを必要とすることです。

統合テスト​

統合テストを実行します。

バグ修正検証チェック​

新しいテスト（無状態または統合）または変更されたテストが、マスターブランチでビルドされたバイナリとともに失敗するかどうかを確認します。 このチェックは、プルリクエストに「pr-bugfix」ラベルが付いたときにトリガーされます。

ストレステスト​

複数のクライアントから無状態関数テストを同時に実行して、同時実行に関連するエラーを検出します。失敗した場合：

  • まず他のすべてのテストの失敗を修正してください；
  • 報告書を見てサーバーログを探し、エラーの可能性のある原因を調べてください。

互換性チェック​

clickhouseバイナリが古いlibcバージョンを持つディストリビューションで実行できるかどうかを確認します。 失敗した場合は、メンテナに援助を求めてください。

ASTファズテスト​

ランダムに生成されたクエリを実行してプログラムエラーをキャッチします。 失敗した場合は、メンテナに援助を求めてください。

パフォーマンステスト​

クエリ性能の変化を測定します。 これは実行に6時間未満を要する最も長いチェックです。 パフォーマンステストレポートの詳細はこちらで説明されています。