継続的インテグレーション (CI)
プルリクエストを送信すると、ClickHouseの 継続的インテグレーション (CI) システム による自動チェックがあなたのコードに対して実行されます。
これは、リポジトリのメンテナ(ClickHouseチームの誰か)があなたのコードを確認し、プルリクエストに can be tested
ラベルを追加した後に行われます。
チェックの結果は、GitHubチェックのドキュメントに記載されているように、GitHubのプルリクエストページに表示されます。
チェックが失敗した場合は、修正する必要があります。
このページでは、遭遇する可能性のあるチェックの概要と、それを修正するためにできることを示します。
チェックの失敗があなたの変更に関連していないように見える場合、それは一時的な失敗やインフラストラクチャの問題である可能性があります。 CIチェックを再起動するために、プルリクエストに空のコミットをプッシュします:
何をすべきかわからない場合は、メンテナに助けを求めてください。
マスターへのマージ
PRがマスターにマージできることを確認します。
できない場合は、Cannot fetch mergecommit
というメッセージで失敗します。
このチェックを修正するには、GitHubのドキュメントに記載されているようにコンフリクトを解決するか、gitを使用して master
ブランチをプルリクエストブランチにマージします。
ドキュメントチェック
ClickHouseのドキュメントウェブサイトをビルドしようとします。
ドキュメントに何かを変更した場合、失敗することがあります。
最も考えられる理由は、ドキュメント内のいくつかの相互リンクが間違っていることです。
チェックレポートに移動し、ERROR
および WARNING
メッセージを探してください。
説明チェック
プルリクエストの説明が PULL_REQUEST_TEMPLATE.md テンプレートに準拠していることを確認します。 変更のためのチェンジログカテゴリを指定する必要があり(例:バグ修正)、CHANGELOG.md の変更を説明するユーザーが読みやすいメッセージを書く必要があります。
DockerHubへのプッシュ
ビルドおよびテストに使用されるDockerイメージをビルドし、それをDockerHubにプッシュします。
マーカーチェック
このチェックは、CIシステムがプルリクエストの処理を開始したことを示します。 'pending' ステータスの場合、すべてのチェックがまだ開始されていないことを意味します。 すべてのチェックが開始されると、ステータスが 'success' に変更されます。
スタイルチェック
コードベースに対してさまざまなスタイルチェックを実行します。
スタイルチェックジョブの基本的なチェック:
cpp
ci/jobs/scripts/check_style/check_cpp.sh
スクリプトを使用して、単純な正規表現ベースのコードスタイルチェックを実行します(ローカルでも実行可能です)。
失敗した場合は、コードスタイルガイドに従ってスタイルの問題を修正してください。
codespell, aspell
文法ミスやタイプミスをチェックします。
mypy
Pythonコードに対して静的型チェックを実行します。
スタイルチェックジョブをローカルで実行
スタイルチェック ジョブ全体をDockerコンテナでローカルに実行できます:
特定のチェック(例:cpp チェック)を実行するには:
これらのコマンドは clickhouse/style-test
Dockerイメージをプルし、コンテナ化された環境でジョブを実行します。
Python 3とDockerを除いて、他に依存関係は必要ありません。
ファストテスト
通常、これはPRのために最初に実行されるチェックです。 ClickHouseをビルドし、いくつかを省略しながらほとんどの ステートレス機能テスト を実行します。 これが失敗すると、修正されるまでさらなるチェックは開始されません。 どのテストが失敗しているかを確認するためにレポートを見て、こちら に記載されているようにローカルで失敗を再現します。
ローカルでファストテストを実行する
これらのコマンドは clickhouse/fast-test
Dockerイメージをプルし、コンテナ化された環境でジョブを実行します。
Python 3とDockerを除いて、他に依存関係は必要ありません。
ビルドチェック
さまざまな構成でClickHouseをビルドし、次のステップで使用します。
ローカルでビルドを実行
CIに似た環境でローカルにビルドを実行するには:
Python 3とDockerを除いて、他に依存関係は必要ありません。
利用可能なビルドジョブ
ビルドジョブ名は、CIレポートに表示されるものと正確に一致します:
AMD64 ビルド:
Build (amd_debug)
- シンボル付きデバッグビルドBuild (amd_release)
- 最適化されたリリースビルドBuild (amd_asan)
- アドレスサニタイザー付きビルドBuild (amd_tsan)
- スレッドサニタイザー付きビルドBuild (amd_msan)
- メモリサニタイザー付きビルドBuild (amd_ubsan)
- 未定義の動作サニタイザー付きビルドBuild (amd_binary)
- Thin LTOなしのクイックリリースビルドBuild (amd_compat)
- 古いシステム向けの互換性ビルドBuild (amd_musl)
- musl libcを使用したビルドBuild (amd_darwin)
- macOSビルドBuild (amd_freebsd)
- FreeBSDビルド
ARM64 ビルド:
Build (arm_release)
- ARM64最適化されたリリースビルドBuild (arm_asan)
- ARM64アドレスサニタイザー付きビルドBuild (arm_coverage)
- カバレッジ計測付きのARM64ビルドBuild (arm_binary)
- Thin LTOなしのARM64クイックリリースビルドBuild (arm_darwin)
- macOS ARM64ビルドBuild (arm_v80compat)
- ARMv8.0互換ビルド
その他のアーキテクチャ:
Build (ppc64le)
- PowerPC 64ビットリトルエンディアンBuild (riscv64)
- RISC-V 64ビットBuild (s390x)
- IBM System/390 64ビットBuild (loongarch64)
- LoongArch 64ビット
ジョブが成功すると、ビルド結果は <repo_root>/ci/tmp/build
ディレクトリに保存されます。
注意: 「その他のアーキテクチャ」カテゴリに含まれないビルド(クロスコンパイルを使用するもの)では、ローカルマシンのアーキテクチャがビルドタイプと一致している必要があります。
例
ローカルデバッグビルドを実行するには:
上記の方法がうまくいかない場合は、ビルドログからcmakeオプションを使用し、一般的なビルドプロセスに従ってください。
ステートレス機能テスト
さまざまな構成でビルドされたClickHouseバイナリのための ステートレス機能テスト を実行します。 レポートを見て、どのテストが失敗しているかを確認し、こちら に記載されているようにローカルで失敗を再現します。 正しいビルド構成を使用して再現する必要があることに注意してください。テストはアドレスサニタイザーの下で失敗する可能性がありますが、デバッグでは通過するかもしれません。 CIビルドチェックページ からバイナリをダウンロードするか、ローカルでビルドしてください。
統合テスト
統合テストを実行します。
バグ修正検証チェック
新しいテスト(機能または統合)または、マスターブランチでビルドされたバイナリに対して失敗する変更されたテストがあることを確認します。 このチェックは、プルリクエストに "pr-bugfix" ラベルが付けられたときにトリガーされます。
ストレステスト
複数のクライアントから同時にステートレス機能テストを実行し、同時実行関連のエラーを検出します。これが失敗した場合:
- 最初に他のすべてのテストの失敗を修正してください;
- レポートを見てサーバーログを見つけ、エラーの可能な原因を確認してください。
互換性チェック
clickhouse
バイナリが古いlibcバージョンを持つディストリビューションで動作することを確認します。
失敗した場合は、メンテナに助けを求めてください。
ASTファジング
ランダムに生成されたクエリを実行してプログラムエラーをキャッチします。 失敗した場合は、メンテナに助けを求めてください。
パフォーマンステスト
クエリパフォーマンスの変化を測定します。 これは、実行にちょうど6時間未満かかる最も長いチェックです。 パフォーマンステストレポートについての詳細は こちら に記載されています。