verify

検証スキル

コミットまたは PR の作成前に、完全な検証を実行してください。

使用方法

変更を確定する前に、包括的なチェックを実行するにはこのスキルを使用します。

手順

変更されたコード（C、Rust、または両方）を特定し、該当するチェックを実行してください。

依存関係、.install/、ブートストラップターゲット、ツールチェーンのバージョン、または CI のプロビジョニングを変更した場合は、 まず ブートストラップと依存関係の変更に従ってください。

C コードを変更した場合

以下のチェックを順番に実行してください。

1. ビルド

./build.sh

エラーとして扱われる警告がなく、プロジェクト全体をコンパイルできることを確認してください。

2. C/C++ 単体テスト

./build.sh RUN_UNIT_TESTS ENABLE_ASSERT=1

すべての単体テストに合格する必要があります。特定のテストの実行方法については、/run-c-unit-testsを参照してください。

3. 動作テスト

./build.sh RUN_PYTEST ENABLE_ASSERT=1

コマンドハンドラー、クエリ実行、インデックス作成パイプライン、または RDB シリアライズを変更した場合に必須です。

4. AddressSanitizer（メモリ関連の変更で推奨）

./build.sh RUN_UNIT_TESTS SAN=address

メモリ安全性のバグを修正したとする変更の場合は、以下の*メモリ安全性の修正（どちらの言語でも）*にも従ってください。

5. コーディネーターテスト（coord/ のコードを変更した場合）

コーディネーター（src/coord/）、分散ハイブリッド（src/coord/hybrid/）、または Map-Reduce レイヤー（src/coord/rmr/）への変更は、クラスター環境でテストする必要があります。

./build.sh RUN_PYTEST ENABLE_ASSERT=1 REDIS_STANDALONE=0 SHARDS=3

3 シャードのクラスターを起動し、そのクラスターに対してテストスイート全体を実行します。

Rust コードを変更した場合

1. フォーマットチェック

make fmt CHECK=1

失敗した場合は、make fmtを実行してフォーマットを修正してください。

2. lint チェック

make lint

clippy の警告やエラーを修正してください。

3. ビルド

./build.sh

プロジェクト全体をコンパイルできることを確認してください。

4. Rust テスト

cargo nextest run --manifest-path src/redisearch_rs/Cargo.toml

すべての Rust テストに合格する必要があります。

メモリ安全性のバグを修正したとする変更の場合は、以下の*メモリ安全性の修正（どちらの言語でも）*にも従ってください。

C と Rust の両方を変更した場合

上記の両方のセクションにあるすべてのチェックを実行してください。

メモリ安全性の修正（どちらの言語でも）

メモリ安全性のバグ（範囲外アクセス、解放後使用）の修正を主張する場合は、修正前のコードで、実際に実行したサニタイザーによる再現テストを一度実行してバグを実証してください。予測されたレポートは検証になりません。修正前のコードではサニタイザーのレポートが出て、修正後は問題なく実行されることを確認してください。

C の場合、手軽な方法なら ASan ビルドツリーは不要です。修正前のリビジョンから対象ファイルを抽出し、たとえば次のようにスタンドアロンの再現テストに対してコンパイルします。

git show HEAD:src/<file>.c > /tmp/before_fix.c           # fix not yet committed (the usual case)
git show <fix-commit>^:src/<file>.c > /tmp/before_fix.c  # fix already committed
clang -fsanitize=address -g -O0 <repro.c> /tmp/before_fix.c -o repro && ./repro

src/ のほとんどのファイルは、そのままではスタンドアロンでコンパイルできません。再現テスト用のディレクトリに最小限の定義を用意して、-I パスを追加し、重いインクルード（rm_malloc、RS_ABORT、モジュールヘッダー）をスタブに置き換える必要があると考えてください。こうしたスタブの作成は、通常は数時間ではなく数分の作業です。

再現テストは、一貫性のある修正前のベースラインに対してビルドする必要があります。修正がヘッダー、マクロ、または抽出したファイルが依存するインラインヘルパーにも及ぶ場合は、それらも同じ修正前のリビジョンから抽出してください。修正前の .c を修正後のヘッダーに対してコンパイルすると、混在したプログラムをテストすることになり、バグが隠れたり、無関係な理由で失敗したりする可能性があります。依存ファイルが数個を超える場合は、修正前のリビジョンをチェックアウトした worktree の方が簡単です。

Rust の場合は、修正前のコードで失敗するケースを Miri の下で実行してください（cargo +nightly miri test --manifest-path src/redisearch_rs/Cargo.toml -p <crate>）。Miri では検出できないバグ（FFI、外部メモリ）には、対象テストを ASan ビルドで実行してください。cargo はクレート全体をビルドするため、ここでは単一ファイルの抽出は機能しません。また、現在のチェックアウトにはすでに修正が含まれているため、そこで Miri を実行しても、修正後のコードに問題がないことしか示せません。まず修正前のツリーをチェックアウトしてください。

git worktree add --detach /tmp/prefix_tree HEAD           # fix not yet committed (the usual case)
git worktree add --detach /tmp/prefix_tree <fix-commit>^  # fix already committed

失敗するテストを修正と同時に追加した場合は、そのテストだけを修正前のツリーにコピーしてください。worktree を指す --manifest-path を指定して Miri または ASan を実行し、そこで失敗することと、修正後のチェックアウトでは問題なく実行されることを確認してから、git worktree remove --force /tmp/prefix_treeで後片付けしてください。

動作テスト（どちらの言語でも重要な変更の場合）

./build.sh RUN_PYTEST ENABLE_ASSERT=1

ライブサーバーでの動作の確認

テストスイートで証明できるのは、テストで検証している内容だけです。実際の redis-server でユーザーに見える変更の動作を確認したり、報告された問題を手作業で再現したりするには、 /drive-redisearch に従ってください。

クイック検証

小規模な Rust のみの変更の場合（サブシェルを使うと、ディレクトリ移動 1 回、コマンド 3 つで一連の操作を見やすくできます）：

(cd src/redisearch_rs && cargo fmt --check && cargo clippy --all-targets && cargo nextest run)

小規模な C のみの変更の場合：

./build.sh && ./build.sh RUN_UNIT_TESTS ENABLE_ASSERT=1