Wie man Bencher in GitLab CI/CD verwendet

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

• Target Branch
• Merge Requests

Stellen Sie sicher, dass Sie ein API-Token erstellt haben und es als maskierte Variable mit dem Namen BENCHER_API_TOKEN festlegen, bevor Sie fortfahren! Navigieren Sie zu Ihr Repo -> Einstellungen -> CI/CD -> Variablen -> Erweitern -> Variable hinzufügen. Der Variablen-Schlüssel sollte BENCHER_API_TOKEN und der Variablen-Wert Ihr API-Token sein. Aktivieren Sie die Kästchen für Variable schützen und Variable maskieren.

Ziel-Branch

Ein Eckpfeiler des Statistical Continuous Benchmarking ist das Vorhandensein einer historischen Basislinie für Ihren Ziel-Branch. Diese historische Basislinie kann dann verwendet werden, um Leistungsregressionen in Merge Requests zu erkennen.

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 save-walter-white-1234abcd \
      --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. Erstellen Sie eine GitLab CI/CD-Datei. (z.B.: .gitlab-ci.yml)
2. Erstellen Sie einen GitLab CI/CD-Job. (z.B.: benchmark_target_branch)
3. Führen Sie das Kommando if aus, wenn die Pipeline durch einen push auf den main-Branch ausgelöst wurde. Siehe die GitLab CI/CD rules Dokumentation und die GitLab CI/CD vordefinierten Variablen Dokumentation für einen umfassenden Überblick. (z.B.: rules: if: ...)
4. Legen Sie das image fest, in dem der Job ausgeführt wird. Siehe die GitLab CI/CD image Dokumentation für einen vollständigen Überblick. (z.B.: image: debian:bullseye)
5. Installieren Sie die Bencher CLI mit dem Convenience-Skript. (z.B.: before_script: ...)
6. Verwenden Sie den bencher run CLI-Unterbefehl, um Ihre main-Branch-Benchmarks auszuführen. Siehe den bencher run CLI-Unterbefehl für eine vollständige Übersicht. (z.B.: bencher run)
7. Setzen Sie die --project-Option auf den Project-Slug. Siehe die --project-Dokumentation für weitere Details. (z.B.: --project save-walter-white-1234abcd)
8. Setzen Sie die --token-Option auf die maskierte BENCHER_API_TOKEN Umgebungsvariable. Siehe die --token-Dokumentation für weitere Details. (z.B.: --token "$BENCHER_API_TOKEN")
9. Setzen Sie die --branch-Option auf den Branch-Namen. Siehe die --branch-Dokumentation für einen vollständigen Überblick. (z.B.: --branch main)
10. Setzen Sie die --testbed-Option auf den Testbed-Namen. Dies sollte wahrscheinlich mit der in image ausgewählten Maschine übereinstimmen. Siehe die --tested-Dokumentation für weitere Details. (z.B.: --testbed debian:bullseye)
11. Setzen Sie die Schwelle für den main-Branch, debian:bullseye Testbed, und latency Measurement:
    1. Setzen Sie die --threshold-measure-Option auf das eingebaute latency Measurement, das durch den bencher mock erzeugt wird. Siehe die --threshold-measure-Dokumentation für weitere Details. (z.B.: --threshold-measure latency)
    2. Setzen Sie die --threshold-test-Option auf einen t-Test (t_test). Siehe die --threshold-test-Dokumentation für einen vollständigen Überblick. (z.B.: --threshold-test t_test)
    3. Setzen Sie die --threshold-max-sample-size-Option auf die maximale Stichprobengröße von 64. Siehe die --threshold-max-sample-size-Dokumentation für weitere Details. (z.B.: --threshold-max-sample-size 64)
    4. Setzen Sie die --threshold-upper-boundary-Option auf die obere Grenze von 0,99. Siehe die --threshold-upper-boundary-Dokumentation für weitere Details. (z.B.: --threshold-upper-boundary 0.99)
    5. Setzen Sie das --thresholds-reset-Flag, sodass nur die festgelegte Schwelle aktiv ist. Siehe die --thresholds-reset-Dokumentation für einen vollständigen Überblick. (z.B.: --thresholds-reset)
12. Setzen Sie das --err-Flag, um den Befehl zu beenden, wenn eine Warnung generiert wird. Siehe die --err-Dokumentation für einen vollständigen Überblick. (z.B.: --err)
13. Setzen Sie die --adapter-Option auf Bencher Metric Format JSON (json), das durch den bencher mock erzeugt wird. Siehe Benchmark-Harness-Adapter für einen vollständigen Überblick. (z.B.: --adapter json)
14. Geben Sie die Argumente des Benchmark-Kommandos an. Siehe Benchmark-Kommando für einen vollständigen Überblick. (z.B.: bencher mock)

Merge Requests

Um Leistungsregressionen in Merge Requests zu erkennen, müssen Sie Ihre Benchmarks auf MRs ausführen. Das untenstehende Beispiel sollte nur für Branches innerhalb desselben Repositories verwendet werden.

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 save-walter-white-1234abcd \
      --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. Aktualisieren Sie die GitLab CI/CD-Datei. (z.B.: .gitlab-ci.yml)
2. Erstellen Sie einen GitLab CI/CD-Job. (z.B.: benchmark_mr_branch)
3. Führen Sie if aus, wenn die Pipeline durch ein merge_request_event ausgelöst wurde. Siehe die GitLab CI/CD rules Dokumentation und GitLab CI/CD vordefinierte Variablen Dokumentation für einen vollständigen Überblick. (z.B.: rules: if: ...)
4. Legen Sie das image fest, in dem der Job ausgeführt wird. Siehe die GitLab CI/CD image Dokumentation für einen vollständigen Überblick. (z.B.: image: debian:bullseye)
5. Installieren Sie die Bencher CLI mit dem convenience script. (z.B.: before_script: ...)
6. Verwenden Sie den bencher run CLI-Unterbefehl, um Ihre Merge Request Branch Benchmarks auszuführen. Siehe den bencher run CLI-Unterbefehl für einen vollständigen Überblick. (z.B.: bencher run)
7. Setzen Sie die --project Option auf den Projekt-Slug. Siehe die --project Dokumentation für mehr Details. (z.B.: --project save-walter-white-1234abcd)
8. Setzen Sie die --token Option auf die maskierte Umgebungsvariable BENCHER_API_TOKEN. Siehe die --token Dokumentation für mehr Details. (z.B.: --token "$BENCHER_API_TOKEN")
9. Setzen Sie die --branch Option auf den Namen des MR-Branches mit einer vordefinierten GitLab CI/CD Variablen. Siehe die --branch Dokumentation für einen vollständigen Überblick. (z.B.: --branch "$CI_COMMIT_REF_NAME")
10. Setzen Sie den Startpunkt für den MR-Branch:
    1. Setzen Sie die --start-point Option auf den Startpunkt des MR-Branches mit einer vordefinierten GitLab CI/CD Variablen. Siehe die --start-point Dokumentation für einen vollständigen Überblick. (z.B.: --start-point "$CI_MERGE_REQUEST_TARGET_BRANCH_NAME")
    2. Setzen Sie die --start-point-hash Option auf den git-Hash des Startpunktes des MR-Branches mit einer vordefinierten GitLab CI/CD Variablen. Siehe die --start-point-hash Dokumentation für einen vollständigen Überblick. (z.B.: --start-point-hash "$CI_MERGE_REQUEST_TARGET_BRANCH_SHA")
    3. Setzen Sie das --start-point-clone-thresholds Flag, um die Schwellenwerte vom Startpunkt zu klonen. Siehe die --start-point-clone-thresholds Dokumentation für einen vollständigen Überblick. (z.B.: --start-point-clone-thresholds)
    4. Setzen Sie das --start-point-reset Flag, um den MR-Branch immer auf den Startpunkt zurückzusetzen. Dies verhindert ein Abdriften der Benchmark-Daten. Siehe die --start-point-reset Dokumentation für einen vollständigen Überblick. (z.B.: --start-point-reset)
11. Setzen Sie die --testbed Option auf den Namen des Testbeds. Dies sollte wahrscheinlich die Maschine widerspiegeln, die in image ausgewählt wurde. Siehe die --testbed Dokumentation für mehr Details. (z.B.: --testbed debian:bullseye)
12. Setzen Sie das --err Flag, um den Befehl bei Auslösung eines Alarms zum Abbruch zu bringen. Siehe die --err Dokumentation für einen vollständigen Überblick. (z.B.: --err)
13. Setzen Sie die --adapter Option auf das Bencher Metric Format JSON (json), das durch bencher mock erzeugt wird. Siehe Benchmark-Harness-Adapter für einen vollständigen Überblick. (z.B.: --adapter json)
14. Geben Sie die Argumente für den Benchmarkbefehl an. Siehe Benchmark-Befehl für einen vollständigen Überblick. (z.B.: bencher mock)

Um den MR-Branch nach dem Schließen seines MRs aufzuräumen, können Sie einen separaten Job erstellen, der den MR-Status über die GitLab-API abfragt. Wenn der Status closed ist, archiviert dieser Job den MR-Branch mit dem Befehl bencher archive.

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 save-walter-white-1234abcd \
        --token "$BENCHER_API_TOKEN" \
        --branch "$CI_COMMIT_REF_NAME"
      else
        echo 'Merge request is not `closed`. Skipping archival.'
      fi

1. Aktualisieren Sie die GitLab CI/CD-Datei. (z.B.: .gitlab-ci.yml)
2. Erstellen Sie einen GitLab CI/CD-Job. (z.B.: archive_mr_branch)
3. Führen Sie den Job aus, wenn die Pipeline durch ein merge_request_event ausgelöst wurde. Siehe die GitLab CI/CD rules Dokumentation und die GitLab CI/CD vordefinierte Variablen Dokumentation für einen vollständigen Überblick. (z.B.: rules: if: ...)
4. Setzen Sie das image, in dem der Job ausgeführt wird. Siehe die GitLab CI/CD image Dokumentation für einen vollständigen Überblick. (z.B.: image: debian:bullseye)
5. Installieren Sie die Bencher CLI mit dem Installationsskript. (z.B.: before_script: curl ...)
6. Überprüfen Sie den MR-Status über die GitLab-API. (z.B.: before_script: MR_STATE=$(...))
7. Verwenden Sie das bencher archive CLI-Unterbefehl, um den MR-Branch zu archivieren, wenn der MR-Status closed ist. (z.B.: bencher archive)
8. Setzen Sie die --project Option auf den Projektslug. Siehe die --project Dokumentation für mehr Details. (z.B.: --project save-walter-white-1234abcd)
9. Setzen Sie die --token Option auf die maskierte BENCHER_API_TOKEN Umgebungsvariable. Siehe die --token Dokumentation für mehr Details. (z.B.: --token "$BENCHER_API_TOKEN")
10. Setzen Sie die --branch Option auf den MR-Branch-Namen, indem Sie eine vordefinierte GitLab CI/CD-Variable verwenden. (z.B.: --branch "$CI_COMMIT_REF_NAME")

🐰 Glückwunsch! Du hast gelernt, wie man Bencher in GitLab CI/CD verwendet! 🎉

Weiter geht’s: Übersicht über das Benchmarking ➡