can be tested ラベルを追加した後に行われます。
各チェックの結果は、GitHub の checks ドキュメントで説明されているとおり、GitHub のプルリクエストページに表示されます。
チェックが失敗している場合は、修正が必要になることがあります。
このページでは、遭遇する可能性のあるチェックの概要と、その修正方法を説明します。
チェックの失敗が自分の変更に関係ないように見える場合は、一時的な障害か、インフラストラクチャの問題である可能性があります。
空のコミットをプルリクエストに push して、CI チェックを再実行してください。
master へのマージ
Cannot fetch mergecommit というメッセージが表示されて失敗します。
このチェックを修正するには、GitHub のドキュメント に記載されている手順で競合を解消するか、git を使って master ブランチを自分のプルリクエストのブランチにマージしてください。
ドキュメントチェック
ERROR と WARNING のメッセージを確認してください。
説明の確認
Docker イメージ
公式 Docker ライブラリのテスト
clickhouse/clickhouse-server Docker イメージが正しく動作することを確認するために、official Docker library のテストを実行します。
新しいテストを追加するには、ディレクトリ ci/jobs/scripts/docker_server/tests/$test_name を作成し、その中にスクリプト run.sh を配置します。
テストの詳細については、CI jobs scripts documentation を参照してください。
マーカーチェック
スタイルチェック
cpp
ci/jobs/scripts/check_style/check_cpp.sh スクリプト (ローカルでも実行可能) を使用して、正規表現ベースの簡単なコードスタイルチェックを行います。
失敗した場合は、コードスタイルガイド に従ってスタイルの問題を修正してください。
codespell, aspell
mypy
スタイルチェックジョブをローカルで実行する
clickhouse/style-test Dockerイメージを取得し、コンテナ化された環境でジョブを実行します。
必要なのは Python 3 と Docker のみで、その他の依存関係はありません。
stateless tests を実行する
前提条件
- Python 3 (標準ライブラリのみ)
- Docker
CIジョブをローカルで実行する
- ジョブ名は、CI レポートに表示されている表記を必ずそのまま引用してください (スペースやカンマが含まれる場合があります) 。例:
"Stateless tests (amd_debug, parallel)"。これにより、CI と同じ ClickHouse の設定で、同じテストが実行されます。 - ジョブ名に含まれるアーキテクチャとビルドタイプ (例:
amd_debug) は、CI 固有のラベルです。ローカルで実行する場合、これらは影響しません。ジョブでは、実行中のアーキテクチャ上で、指定したバイナリがそのまま使われます。ジョブ名が決定するのは、ClickHouse の設定とテストセットだけです (--testで上書きした場合を除く) 。 - CI では、リソースをより効率的に使うために、機能テストを複数のバッチに分割しています。たとえば、
"Stateless tests (amd_debug, parallel)"と"Stateless tests (amd_debug, sequential)"を合わせると、テスト対象全体をカバーできます。並列実行しても安全なテストは同時実行され、それ以外は順次実行されます。この分割により、可能な限り並列化して CI の合計実行時間を短縮できます。ローカルでテスト対象全体を再現するには、両方のバッチを実行してください。 - また、ClickHouse の基本的な機能を確認するために、限定的な範囲の機能テストを実行する
"Fast test"CI ジョブもあります。これは、すべてのオプションモジュールを含まないビルドを使用し、リグレッションを最も手早く検出できる方法です。ローカルでも同じ方法で実行できます。ClickHouse バイナリを既定の検索パスのいずれか (./ci/tmp/clickhouse、./build/programs/clickhouse、または./clickhouse) に配置してください。そうしないと、ジョブはまず ClickHouse のビルドを試みます。
CI ジョブ内で特定のテストを実行する
--test を使用すると、ジョブは CI と同一の ClickHouse セットアップを準備し、選択したテストだけを実行します。
- 複数のテスト名を指定できます。
- ヒント: ClickHouse の構成であればどれでも問題なく、特定のテストだけを実行したい場合は、完全な job 名ではなくエイリアス
functionalを使用してください。
追加のカスタマイズオプション
--path PATH— ClickHouse バイナリへのカスタムパス。デフォルトでは、ランナーは./ci/tmp/clickhouse、./build/programs/clickhouse、./clickhouseの順に検索します。--count N— 各テストを N 回繰り返します。--workers N— マシンの性能に基づいて自動計算される並列ワーカー数を上書きします。
ビルドチェック
ビルドをローカルで実行する
利用可能なビルドジョブ
Build (amd_debug)- シンボル付きデバッグビルドBuild (amd_release)- 最適化されたリリースビルドBuild (amd_asan)- Address Sanitizer ビルドBuild (amd_tsan)- Thread Sanitizer ビルドBuild (amd_msan)- Memory Sanitizer ビルドBuild (amd_ubsan)- Undefined Behavior Sanitizer ビルドBuild (amd_binary)- Thin LTO なしの高速リリースビルドBuild (amd_compat)- 古いシステム向けの互換ビルドBuild (amd_musl)- musl libc を使用したビルドBuild (amd_darwin)- macOS ビルドBuild (amd_freebsd)- FreeBSD ビルド
Build (arm_release)- ARM64 向けの最適化リリースビルドBuild (arm_asan)- ARM64 Address Sanitizer ビルドBuild (arm_coverage)- カバレッジ用インストルメンテーションを含む ARM64 ビルドBuild (arm_binary)- Thin LTO なしの ARM64 高速リリースビルドBuild (arm_darwin)- macOS ARM64 ビルドBuild (arm_v80compat)- ARMv8.0 互換ビルド
Build (ppc64le)- PowerPC 64 ビット Little EndianBuild (riscv64)- RISC-V 64 ビットBuild (s390x)- IBM System/390 64 ビットBuild (loongarch64)- LoongArch 64 ビット
<repo_root>/ci/tmp/build ディレクトリで利用できます。
注: 「その他のアーキテクチャ」カテゴリ以外のビルド (クロスコンパイルを使用しないもの) では、BUILD_JOB_NAME で指定したビルドを生成するために、ローカルマシンのアーキテクチャがビルドタイプと一致している必要があります。
例
ステートレスな機能テスト
結合テスト
バグ修正の validate チェック
ストレステスト
- まず、他のすべてのテスト失敗を修正してください。
- レポートを確認してサーバーログを見つけ、エラーの原因となりそうな点がないか確認してください。
互換性チェック
clickhouse バイナリが古い libc バージョンの Linux ディストリビューション上で実行できることを確認します。
失敗した場合は、メンテナーに相談してください。