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

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

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

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

git reset
git commit --allow-empty
git push

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

マスターへのマージ​

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コンテナでローカルに実行できます：

python -m ci.praktika run "Style check"

特定のチェック（例：cpp チェック）を実行するには：

python -m ci.praktika run "Style check" --test cpp

これらのコマンドは clickhouse/style-test Dockerイメージをプルし、コンテナ化された環境でジョブを実行します。 Python 3とDockerを除いて、他に依存関係は必要ありません。

ファストテスト​

通常、これはPRのために最初に実行されるチェックです。 ClickHouseをビルドし、いくつかを省略しながらほとんどの ステートレス機能テスト を実行します。 これが失敗すると、修正されるまでさらなるチェックは開始されません。 どのテストが失敗しているかを確認するためにレポートを見て、こちら に記載されているようにローカルで失敗を再現します。

ローカルでファストテストを実行する​

python -m ci.praktika run "Fast test" [--test some_test_name]

これらのコマンドは clickhouse/fast-test Dockerイメージをプルし、コンテナ化された環境でジョブを実行します。 Python 3とDockerを除いて、他に依存関係は必要ありません。

ビルドチェック​

さまざまな構成でClickHouseをビルドし、次のステップで使用します。

ローカルでビルドを実行​

CIに似た環境でローカルにビルドを実行するには：

python -m ci.praktika run "<BUILD_JOB_NAME>"

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 ディレクトリに保存されます。

注意: 「その他のアーキテクチャ」カテゴリに含まれないビルド（クロスコンパイルを使用するもの）では、ローカルマシンのアーキテクチャがビルドタイプと一致している必要があります。

例​

ローカルデバッグビルドを実行するには：

python -m ci.praktika run "Build (amd_debug)"

上記の方法がうまくいかない場合は、ビルドログからcmakeオプションを使用し、一般的なビルドプロセスに従ってください。

ステートレス機能テスト​

さまざまな構成でビルドされたClickHouseバイナリのための ステートレス機能テスト を実行します。 レポートを見て、どのテストが失敗しているかを確認し、こちら に記載されているようにローカルで失敗を再現します。 正しいビルド構成を使用して再現する必要があることに注意してください。テストはアドレスサニタイザーの下で失敗する可能性がありますが、デバッグでは通過するかもしれません。 CIビルドチェックページ からバイナリをダウンロードするか、ローカルでビルドしてください。

統合テスト​

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

バグ修正検証チェック​

新しいテスト（機能または統合）または、マスターブランチでビルドされたバイナリに対して失敗する変更されたテストがあることを確認します。 このチェックは、プルリクエストに "pr-bugfix" ラベルが付けられたときにトリガーされます。

ストレステスト​

複数のクライアントから同時にステートレス機能テストを実行し、同時実行関連のエラーを検出します。これが失敗した場合：

  • 最初に他のすべてのテストの失敗を修正してください；
  • レポートを見てサーバーログを見つけ、エラーの可能な原因を確認してください。

互換性チェック​

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

ASTファジング​

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

パフォーマンステスト​

クエリパフォーマンスの変化を測定します。 これは、実行にちょうど6時間未満かかる最も長いチェックです。 パフォーマンステストレポートについての詳細は こちら に記載されています。