bencher run CLI サブコマンド
bencher runは最も人気のあるCLIサブコマンドです。
これはベンチマークを実行し、結果を報告するために使用されます。
したがって、それは最も複雑なサブコマンドの一つです。
このページでは、bencher runに渡すことができるオプション、フラグ、引数を説明します。
bencher run [OPTIONS] [COMMAND] [ARGUMENTS...]ベンチマークコマンド
bencher runへの最初の引数は、オプションのベンチマークコマンドです。
これは実行されるコマンドで、ベンチマークハーネスを呼び出します。
BENCHER_CMD環境変数を使用して設定することもできます。
デフォルトではこのコマンドはシェルで実行され、--shell オプションと --flag オプションで設定することができます。
その出力はベンチマークハーネスアダプターによって解析され、--adapter オプションを使用して設定します。
しかし、ベンチマークハーネスがファイルに出力する場合は、出力ファイルのパスを指定するためにも--file オプションを使用しなければなりません。
出力ファイルのサイズ（つまりバイナリサイズ）をその内容の代わりに追跡するためには、出力ファイルのパスを指定する--file-size オプションを使用します。
コマンドをシェルで実行したくない場合は、--exec フラグを使用するか、追加の引数を bencher run への追加の引数として提供することができます。
Shell Form:
bencher run "bencher mock"Exec Form:
bencher run bencher mock--iter オプションを使用してベンチマークコマンドを複数回実行し、--fold オプションを使用してそれらの結果を単一の結果にまとめることができます。
いずれかの反復が失敗した場合、--allow-failure フラグが設定されていない限り、コマンド全体が失敗とみなされます。
ベンチマークコマンドが指定されていないが--file オプションが指定されている場合、bencher runは代わりに出力ファイルパスから読み取ります。
同様に、ベンチマークコマンドが指定されていないが--file-size オプションが指定されている場合、bencher runは指定されたファイルパスのファイルサイズを読み取ります。
ベンチマークコマンド、--file オプション、--file-size オプションのいずれも指定されていない場合、bencher runは代わりに stdin から読み取ります。
これにより、他のコマンドの出力をファイルに保存するか、bencher runにパイプすることができます。
Options
--project <PROJECT>
--projectオプションまたはBENCHER_PROJECT環境変数のどちらかを
既存のプロジェクトのスラグまたはUUIDに設定する必要があります。
両方が定義されている場合、--projectオプションはBENCHER_PROJECT環境変数に優先します。
--token <TOKEN>
--tokenオプションまたはBENCHER_API_TOKEN環境変数のどちらかを有効なAPIトークンに設定する必要があります。
両方が定義されている場合、--tokenオプションはBENCHER_API_TOKEN環境変数に優先します。
--branch <BRANCH>
--start-point <BRANCH>
--start-point-hash <HASH>
--start-point-max-versions <COUNT>
--start-point-clone-thresholds
--start-point-reset
詳細については、ブランチ選択をご覧ください。
--hash <HASH>
オプション：40文字のSHA-1コミットハッシュ。 2つのレポートが同じブランチとハッシュを持っている場合、それらは同じコミットから来たものと見なされます。 したがって、それらは同じブランチバージョン番号を持つでしょう。
提供されない場合、Bencher CLIは現在のgitハッシュを見つけようとします。 最初に、現在の作業ディレクトリでgitリポジトリを探します。 見つからない場合、親ディレクトリに移動してルートディレクトリまで再試行を続けます。 gitリポジトリが見つかった場合、現在のブランチのHEAD gitハッシュが使用されます。
--no-hash
任意: git コミットハッシュを探さないようにします。
このオプションは--hashと競合し、
git リポジトリを検索するそのデフォルトの動作を上書きします。
--testbed <TESTBED>
オプション：--testbedオプションまたはBENCHER_TESTBED環境変数のいずれかを既存のテストベッドのスラグまたはUUIDに設定することができます。
両方が定義されている場合、--testbedオプションはBENCHER_TESTBED環境変数に優先します。
どちらも定義されていない場合、デフォルトのテストベッドとしてlocalhostが使用されます。
--threshold-measure <MEASURE>
--threshold-test <TEST>
--threshold-min-sample-size <SAMPLE_SIZE>
--threshold-max-sample-size <SAMPLE_SIZE>
--threshold-window <WINDOW>
--threshold-lower-boundary <BOUNDARY>
--threshold-upper-boundary <BOUNDARY>
--thresholds-reset
--err
詳しくは、しきい値とアラートをご覧ください。
--adapter <ADAPTER>
--average <AVERAGE>
--file <FILE>
--build-time
--file-size <FILE>
完全な概要については、benchmark harness adapterを参照してください。
--iter <COUNT>
オプション：実行繰り返し数。デフォルトは1です。
--fold <AGGREGATE_FUNCTION>
オプション：複数の結果を一つの結果にまとめます。
必要条件：--iterが設定されていること。
可能な値:
min: 最小値max: 最大値mean: 値の平均median: 値の中央値
--backdate <SECONDS>
オプション：レポートのバックデート（エポックからの秒数）。 注：これは過去のレポートの並べ替えに影響を及ぼしません！ これは、プロジェクトに初めて歴史的データを_時系列_順にシーディングする際に便利です。
--allow-failure
オプション：ベンチマークテストの失敗を許可する。
--format <FORMAT>
オプション: 最終レポートのフォーマット。
デフォルトは human です。
考えられる値:
human: 人間が読む形式json: JSON形式html: HTML形式
--quiet
オプション: レポートの最終結果のみを出力する簡易モードです。
出力形式を変更するには、こちらの --format オプションを使用してください。
--github-actions <GITHUB_TOKEN>
オプション: GitHub API認証トークンを設定します。
これを行う最も便利な方法は、GitHub Actions GITHUB_TOKEN 環境変数を使用することです（例：--github-actions ${{ secrets.GITHUB_TOKEN }}）。
このオプションが設定され、GitHub Actions内でbencher runがプルリクエストの一部として使用されると、結果はコメントとしてプルリクエストに追加されます。
これにはトークンがpull-requests スコープに対するwrite権限を持っている必要があります。
そうでなければ、結果はコミットに対するGitHubチェックとして追加されます。
これにはトークンがchecks スコープに対するwrite権限を持っている必要があります。
いずれの場合でも、結果はジョブサマリーにも追加されます。
🐰 GitHub Action内でDockerコンテナを実行している場合、以下の環境変数を渡し、
GITHUB_EVENT_PATHで指定されたパスをマウントする必要があります：
GITHUB_ACTIONSGITHUB_EVENT_NAMEGITHUB_EVENT_PATHGITHUB_SHA
--ci-only-thresholds
オプション: しきい値が存在するブランチ、テストベッド、および測定のためのCIのみに結果を投稿します。
しきい値が存在しない場合は、何も投稿されません。
必要条件: --github-actions
--ci-only-on-alert
任意: アラートが生成された場合にのみCIに結果を投稿します。
アラートが生成されると、その後のすべての結果もアラートが含まれていなくても投稿されます。
必要条件: --github-actions
--ci-id <ID>
オプション: CIに結果を投稿するためのカスタムID。
デフォルトでは、Bencherは結果をプロジェクト、ブランチ、テストベッド、およびアダプターの組み合わせで自動的に区切ります。
同じプロジェクト、ブランチ、テストベッド、アダプターの組み合わせで、同じCIワークフロー内でBencherを複数回実行する場合にカスタムIDを設定することが有用です。
必要条件: --github-actions
--ci-number <NUMBER>
オプション: CIに結果を投稿するための課題番号。
BencherはCI結果を投稿するために必要な課題番号を自動検出しようとします。
ただし、GitHub Actionsでworkflow_runを使用するような複雑な設定では、必ずしも利用できるとは限りません。
必要条件: --github-actions
--shell <SHELL>
オプション: シェルコマンドパス。
Unix系環境ではデフォルトは /bin/sh、Windowsでは cmd です。
--flag <FLAG>
オプション: シェルコマンドのフラグ。 Unix系環境ではデフォルトで -c が使用され、Windowsでは /C が使用されます。
--exec
オプション: シェルコマンドではなく、実行可能なコマンドとして実行します。
bencher runへの引数の数が1つ以上の場合のデフォルトです。
--host <URL>
オプション: バックエンドホストのURL。 デフォルトはBench Cloud: https://api.bencher.dev
--attempts <COUNT>
オプション: リクエスト再試行の最大回数を指定します。
デフォルトは10回の試行です。
--retry-after <SECONDS>
オプション: 試行間に待機する初期秒数（指数バックオフ）。
デフォルトは1秒です。
--dry-run
任意: ドライランを実行します。これにより、バックエンドにデータが保存されることはありません。レポート、ブランチ（ブランチの選択で詳述）、またはテストベッドは作成されません。
--help
オプション: ヘルプを表示します。
🐰 おめでとう！
bencher runの基本を学びました！🎉