thevar1able/ClickHouse
1
0
Fork 0
mirror of https://github.com/ClickHouse/ClickHouse.git synced 2024-12-04 05:22:17 +00:00
Code Issues Packages Projects Releases Wiki Activity
c70bf58d9c
ClickHouse/docs/ja/development/continuous-integration.md
Miki Matsumoto 1e15312729 add translated Japanese docs
2024-11-18 11:58:58 +09:00

12 KiB
Raw Blame History

slug sidebar_position sidebar_label title description
/ja/development/continuous-integration 62 Continuous Integration Checks Continuous Integration Checks プルリクエストを送信すると、ClickHouseの継続的インテグレーション (CI) システムにより自動化されたチェックがコードに対して実行されます

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

チェックの失敗が変更内容とは関係ないように見える場合、それは一時的な失敗やインフラの問題かもしれません。プルリクエストに空のコミットをプッシュして、CIチェックを再起動してください。

git reset
git commit --allow-empty
git push

どうすればよいか分からない場合は、管理者に助けを求めてください。

Merge With Master

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

Docs check

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

Description Check

プルリクエストの説明がテンプレートPULL_REQUEST_TEMPLATE.mdに準拠しているかチェックします。変更に対する変更ログカテゴリ（例: Bug Fix）を指定し、CHANGELOG.mdに変更を説明するユーザー向けメッセージを書かなければなりません。

Push To DockerHub

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

Marker Check

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

Style Check

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

ローカルでスタイルチェックを実行する:

mkdir -p /tmp/test_output
# 全てのチェックを実行
python3 tests/ci/style_check.py --no-push

# 指定されたチェックスクリプトを実行（例: ./check-mypy）
docker run --rm --volume=.:/ClickHouse --volume=/tmp/test_output:/test_output -u $(id -u ${USER}):$(id -g ${USER}) --cap-add=SYS_PTRACE --entrypoint= -w/ClickHouse/utils/check-style clickhouse/style-test ./check-mypy

# スタイルチェックスクリプトがあるディレクトリへ移動:
cd ./utils/check-style

# 重複インクルードをチェック
./check-duplicate-includes.sh

# C++フォーマットをチェック
./check-style

# Pythonフォーマットをblackでチェック
./check-black

# Pythonの型ヒントをmypyでチェック
./check-mypy

# flake8でPythonをチェック
./check-flake8

# codespellでコードをチェック
./check-typos

# ドキュメントのスペルをチェック
./check-doc-aspell

# 空白をチェック
./check-whitespaces

# GitHub Actionsのワークフローをチェック
./check-workflows

# サブモジュールをチェック
./check-submodules

# shellcheckでシェルスクリプトをチェック
./shellcheck-run.sh

Fast Test

通常これはPRに対して最初に実行されるチェックです。ClickHouseのビルドと、多くのステートレス機能テストが実行されますが、一部は省略されます。これが失敗すると、それが修正されるまでさらなるチェックは開始されません。どのテストが失敗したかを確認し、それをローカルで再現する方法はこちらにあります。

ローカルでFast Testを実行する:

mkdir -p /tmp/test_output
mkdir -p /tmp/fasttest-workspace
cd ClickHouse
# このdockerコマンドは最小限のClickHouseビルドを行い、FastTestsを実行します
docker run --rm --cap-add=SYS_PTRACE -u $(id -u ${USER}):$(id -g ${USER})  --network=host -e FASTTEST_WORKSPACE=/fasttest-workspace -e FASTTEST_OUTPUT=/test_output -e FASTTEST_SOURCE=/ClickHouse --cap-add=SYS_PTRACE -e stage=clone_submodules --volume=/tmp/fasttest-workspace:/fasttest-workspace --volume=.:/ClickHouse --volume=/tmp/test_output:/test_output clickhouse/fasttest

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

  • 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フラグチェックに関するメッセージが含まれます。

ステータスページのカラム

  • Test name：テストの名前（パスを除く、例えばすべてのタイプのテストは名前に統合されます）。
  • Test status -- Skipped, Success, _Fail_のいずれか。
  • Test time, sec. -- このテストでは空白です。

ビルドチェック

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

レポート詳細

  • Compiler: clang-18、オプションでターゲットプラットフォームの名前
  • Build type: DebugまたはRelWithDebInfo (cmake)。
  • Sanitizer: none（サニタイザーなし）、address (ASan)、memory (MSan)、undefined (UBSan)、またはthread (TSan)。
  • Status: successまたはfail
  • Build log: ビルドおよびファイルコピーのログへのリンク、ビルド失敗時に役立ちます。
  • Build time。
  • Artifacts: ビルド結果ファイル（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を実行する:

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

mkdir build_tidy
./docker/packager/packager --output-dir=./build_tidy --package-type=binary --compiler=clang-18 --debug-build --clang-tidy

Stateless 機能テスト

さまざまな構成でビルドされたClickHouseバイナリに対して、ステートレス機能テストを実行します。どのテストが失敗したかを確認し、それをローカルで再現する方法はこちらにあります。正しいビルド構成を使用して再現する必要があることに注意してください。アドレスサニタイザ（AddressSanitizer）で失敗するテストがデバッグで成功する可能性があります。バイナリをCIビルドチェックページからダウンロードするか、ローカルでビルドしてください。

Stateful 機能テスト

Stateful 機能テストを実行します。ステートレス機能テストと同様に扱います。違いはclickstreamデータセットからhitsおよびvisitsテーブルが必要なことです。

統合テスト

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

バグ修正検証チェック

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

ストレステスト

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

  • まずすべての他のテストの失敗を修正してください;
  • レポートを見て、サーバーログをチェックし、エラーの可能性のある原因を調べてください。

互換性チェック

clickhouseバイナリが古いlibcバージョンのディストリビューションで実行されることを確認します。失敗した場合、管理者に助けを求めてください。

AST ファジング

プログラムエラーを発見するためにランダムに生成されたクエリを実行します。失敗した場合は、管理者に助けを求めてください。

パフォーマンステスト

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