GitLab CI/CDでBencherを使用する方法

Depending on your use case, you can set up Continuous Benchmarking in GitLab CI/CD for your:

• Target Branch
• Merge Requests

確実に、APIトークンを作成し 、続行する前にマスクされた変数 BENCHER_API_TOKEN として設定してください！ Your Repo -> Settings -> CI/CD -> Variables -> Expand -> Add variable に移動します。 変数キーは BENCHER_API_TOKEN であり、変数値はあなたのAPIトークンであるべきです。 Protect variable と Mask variable のボックスの両方をチェックしてください。

ターゲットブランチ

統計的継続的ベンチマークの基盤となるのは、ターゲットブランチの履歴ベースラインを持つことです。 この履歴ベースラインを使用して、マージリクエストにおけるパフォーマンスの低下を検出できます。

benchmark_target_branch:
  rules:
    - if: $CI_COMMIT_BRANCH == "main" && $CI_PIPELINE_SOURCE == "push"
      when: always
  image: debian:bullseye
  before_script:
    - curl --proto '=https' --tlsv1.2 -sSfL https://bencher.dev/download/install-cli.sh | sh
  script:
    - |
      bencher run \
      --project project-abc4567-wxyz123456789 \
      --token "$BENCHER_API_TOKEN" \
      --branch main \
      --testbed debian:bullseye \
      --threshold-measure latency \
      --threshold-test t_test \
      --threshold-max-sample-size 64 \
      --threshold-upper-boundary 0.99 \
      --thresholds-reset \
      --err \
      --adapter json \
      bencher mock

1. GitLab CI/CDファイルを作成します。 (例: .gitlab-ci.yml)
2. GitLab CI/CDジョブを作成します。 (例: benchmark_target_branch)
3. パイプラインがmainブランチへのpushによってトリガーされた場合にのみ実行します。 詳細については、GitLab CI/CDのrulesドキュメンテーションとGitLab CI/CDのあらかじめ定義された変数のドキュメンテーションをご覧ください。 (例: rules: if: ...)
4. ジョブが実行されるimageを設定します。 詳細については、GitLab CI/CDのimage ドキュメンテーションをご覧ください。 (例: image: debian:bullseye)
5. 利便性のためのスクリプトを使用してBencher CLIをインストールします。 (例: before_script: ...)
6. bencher run CLI サブコマンドを使用してmainブランチのベンチマークを実行します。 詳細については、bencher run CLIサブコマンドをご覧ください。 (例: bencher run)
7. プロジェクトスラッグに--projectオプションを設定します。 詳細については、--project ドキュメントをご覧ください。 (例: --project project-abc4567-wxyz123456789)
8. 隠されたBENCHER_API_TOKEN環境変数に--tokenオプションを設定します。 詳細については、--token ドキュメントをご覧ください。 (例: --token "$BENCHER_API_TOKEN")
9. --branchオプションをブランチ名に設定します。 詳細については、--branch ドキュメントをご覧ください。 (例: --branch main)
10. --testbedオプションをテストベッド名に設定します。 これは、おそらくimageで選択したマシンと一致させる必要があります。 詳細については、--testbed ドキュメントをご覧ください。 (例: --testbed debian:bullseye)
11. mainブランチ、debian:bullseyeテストベッド、およびlatency測定基準のための閾値を設定します。
    1. 組み込みのlatency測定基準、bencher mockによって生成されるものに--threshold-measureオプションを設定します。 詳細については、--threshold-measure ドキュメントをご覧ください。 (例: --threshold-measure latency)
    2. スチューデントのt検定(t_test)に--threshold-testオプションを設定します。 詳細については、--threshold-test ドキュメントをご覧ください。 (例: --threshold-test t_test)
    3. 最大サンプルサイズ64に--threshold-max-sample-sizeオプションを設定します。 詳細については、--threshold-max-sample-size ドキュメントをご覧ください。 (例: --threshold-max-sample-size 64)
    4. 上限境界0.99に--threshold-upper-boundaryオプションを設定します。 詳細については、--threshold-upper-boundary ドキュメントをご覧ください。 (例: --threshold-upper-boundary 0.99)
    5. 特定された閾値のみがアクティブであるように--thresholds-resetフラグを設定します。 詳細については、--thresholds-reset ドキュメントをご覧ください。 (例: --thresholds-reset)
12. アラートが生成された場合にコマンドが失敗するように--errフラグを設定します。 詳細については、--err ドキュメントをご覧ください。 (例: --err)
13. bencher mockによって生成されるBencher Metric Format JSON (json)に--adapterオプションを設定します。 詳細については、ベンチマークハーネスアダプタをご覧ください。 (例: --adapter json)
14. ベンチマークコマンドの引数を指定します。 詳細については、ベンチマークコマンドをご覧ください。 (例: bencher mock)

マージリクエスト

マージリクエストでパフォーマンスのリグレッションをキャッチするためには、MR上でベンチマークを実行する必要があります。 以下の例は、同じ リポジトリ内のブランチにのみ使用してください。

benchmark_mr_branch:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      when: always
  image: debian:bullseye
  before_script:
    - curl --proto '=https' --tlsv1.2 -sSfL https://bencher.dev/download/install-cli.sh | sh
  script:
    - |
      bencher run \
      --project project-abc4567-wxyz123456789 \
      --token "$BENCHER_API_TOKEN" \
      --branch "$CI_COMMIT_REF_NAME" \
      --start-point "$CI_MERGE_REQUEST_TARGET_BRANCH_NAME" \
      --start-point-hash "$CI_MERGE_REQUEST_TARGET_BRANCH_SHA" \
      --start-point-clone-thresholds \
      --start-point-reset \
      --testbed debian:bullseye \
      --err \
      --adapter json \
      bencher mock

1. GitLab CI/CD ファイルを更新します。 （例: .gitlab-ci.yml）
2. GitLab CI/CD ジョブを作成します。 （例: benchmark_mr_branch）
3. パイプラインが merge_request_event によってトリガーされた場合に実行します。 GitLab CI/CD rules ドキュメント と GitLab CI/CD 説明変数ドキュメント を参照して、全体像を確認してください。 （例: rules: if: ...）
4. ジョブが実行される image を設定します。 GitLab CI/CD image ドキュメント を参照して、全体像を確認してください。 （例: image: debian:bullseye）
5. 便利なスクリプトを使用してBencher CLIをインストールします。 （例: before_script: ...）
6. bencher run CLIサブコマンド を使用してマージリクエストブランチのベンチマークを実行します。 bencher run CLIサブコマンド を参照して、全体像を確認してください。 （例: bencher run）
7. --project オプションをプロジェクトスラグに設定します。 --project ドキュメント を参照してください。 （例: --project project-abc4567-wxyz123456789）
8. --token オプションをマスクされた BENCHER_API_TOKEN 環境変数に設定します。 --token ドキュメント を参照してください。 （例: --token "$BENCHER_API_TOKEN"）
9. GitLab CI/CD 説明変数 を使用して、--branch オプションをMRブランチ名に設定します。 --branch ドキュメント を参照して、全体像を確認してください。 （例: --branch "$CI_COMMIT_REF_NAME"）
10. MRブランチの開始ポイントを設定します：
    1. GitLab CI/CD 説明変数 を使用して、--start-point オプションをMRブランチの開始ポイントに設定します。 --start-point ドキュメント を参照して、全体像を確認してください。 （例: --start-point "$CI_MERGE_REQUEST_TARGET_BRANCH_NAME"）
    2. GitLab CI/CD 説明変数 を使用して、--start-point-hash オプションをMRブランチの開始ポイントの git ハッシュに設定します。 --start-point-hash ドキュメント を参照して、全体像を確認してください。 （例: --start-point-hash "$CI_MERGE_REQUEST_TARGET_BRANCH_SHA"）
    3. 開始ポイントからしきい値をクローンするために --start-point-clone-thresholds フラグを設定します。 --start-point-clone-thresholds ドキュメント を参照して、全体像を確認してください。 （例: --start-point-clone-thresholds）
    4. ベンチマークデータのドリフトを防ぐため、常にMRブランチを開始ポイントにリセットするために --start-point-reset フラグを設定します。 --start-point-reset ドキュメント を参照して、全体像を確認してください。 （例: --start-point-reset）
11. --testbed オプションをテストベッド名に設定します。 これは、おそらく image で選択したマシンと一致する必要があります。 --tested ドキュメント を参照してください。 （例: --testbed debian:bullseye）
12. アラートが発生した場合にコマンドを失敗させるために --err フラグを設定します。 --err ドキュメント を参照して、全体像を確認してください。 （例: --err）
13. bencher mock によって生成される Bencher Metric Format JSON (json) に --adapter オプションを設定します。 ベンチマークハーネスアダプターadapter json を参照して、全体像を確認してください。 （例: --adapter json）
14. ベンチマークコマンド引数を指定します。 ベンチマークコマンドcommand argument を参照して、全体像を確認してください。 （例: bencher mock）

MRがクローズされた後にMRブランチをクリーンアップするためには、GitLab APIを使用してMRのステートをクエリする別のジョブを作成することができます。 ステートがclosedの場合、このジョブはbencher archiveコマンドを使用してMRブランチをアーカイブします。

archive_mr_branch:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      when: always
  image: debian:bullseye
  before_script:
    - curl --proto '=https' --tlsv1.2 -sSfL https://bencher.dev/download/install-cli.sh | sh
    - |
      MR_STATE=$(curl --header "PRIVATE-TOKEN: $CI_JOB_TOKEN" "https://gitlab.com/api/v4/projects/$CI_PROJECT_ID/merge_requests/$CI_MERGE_REQUEST_IID" | jq -r .state)
      echo "Merge request state: $MR_STATE"
  script:
    - |
      if [ "$MR_STATE" = "closed" ]; then
        bencher archive \
        --project project-abc4567-wxyz123456789 \
        --token "$BENCHER_API_TOKEN" \
        --branch "$CI_COMMIT_REF_NAME"
      else
        echo 'Merge request is not `closed`. Skipping archival.'
      fi

1. GitLab CI/CDファイルを更新します。 （例: .gitlab-ci.yml）
2. GitLab CI/CDジョブを作成します。 （例: archive_mr_branch）
3. パイプラインがmerge_request_eventによってトリガーされた場合に実行します。 完全な概要については、GitLab CI/CD rulesのドキュメントとGitLab CI/CDの事前定義された変数のドキュメントを参照してください。 （例: rules: if: ...）
4. ジョブが実行されるimageを設定します。 完全な概要については、GitLab CI/CD imageのドキュメントを参照してください。 （例: image: debian:bullseye）
5. 便利なスクリプトを使用してBencher CLIをインストールします。 （例: before_script: curl ...）
6. GitLab APIを使用してMRのステートを確認します。 （例: before_script: MR_STATE=$(...)）
7. MRのステートがclosedの場合、bencher archive CLIサブコマンドを使用してMRブランチをアーカイブします。 （例: bencher archive）
8. プロジェクトのスラッグに--projectオプションを設定します。 詳細は --project のドキュメントを参照してください。 （例: --project project-abc4567-wxyz123456789）
9. マスクされたBENCHER_API_TOKEN環境変数を--tokenオプションに設定します。 詳細については --token のドキュメントを参照してください。 （例: --token "$BENCHER_API_TOKEN"）
10. GitLab CI/CDの事前定義された変数を使用してMRブランチ名に--branchオプションを設定します。 （例: --branch "$CI_COMMIT_REF_NAME"）

🐰 おめでとうございます！GitLab CI/CDでBencherを使用する方法を学びました！🎉

続けてください：ベンチマーキング概要 ➡