Comment utiliser Bencher dans GitLab CI/CD

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

• Target Branch
• Merge Requests

Make sure you have created an API token and set it as a masked variable named BENCHER_API_TOKEN before continuing on! Navigate to Your Repo -> Settings -> CI/CD -> Variables -> Expand -> Add variable. The variable key should be BENCHER_API_TOKEN and the variable value should be your API token. Check both the Protect variable and Mask variable boxes.

Branche Cible

Un pilier du Benchmarking Continu Statistique est d’avoir une base historique pour votre branche cible. Cette base historique peut alors être utilisée pour détecter les régressions de performance dans les demandes de fusion.

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. Créez un fichier GitLab CI/CD. (ex : .gitlab-ci.yml)
2. Créez un job GitLab CI/CD. (ex : benchmark_target_branch)
3. Exécutez if le pipeline a été déclenché par un push sur la branche main. Consultez la documentation rules de GitLab CI/CD et la documentation des variables prédéfinies de GitLab CI/CD pour un aperçu complet. (ex : rules: if: ...)
4. Définissez l’image dans laquelle le job s’exécutera. Consultez la documentation image de GitLab CI/CD pour un aperçu complet. (ex : image: debian:bullseye)
5. Installez le Bencher CLI à l’aide du script pratique. (ex : before_script: ...)
6. Utilisez la sous-commande CLI bencher run pour exécuter vos benchmarks de la branche main. Consultez la sous-commande CLI bencher run pour un aperçu complet. (ex : bencher run)
7. Définissez l’option --project sur le slug du projet. Consultez la documentation --project pour plus de détails. (ex : --project project-abc4567-wxyz123456789)
8. Définissez l’option --token sur la variable d’environnement masquée BENCHER_API_TOKEN. Consultez la documentation --token pour plus de détails. (ex : --token "$BENCHER_API_TOKEN")
9. Définissez l’option --branch sur le nom de la branche. Consultez la documentation --branch pour un aperçu complet. (ex : --branch main)
10. Définissez l’option --testbed sur le nom du banc d’essai. Cela doit probablement correspondre à la machine sélectionnée dans image. Consultez la documentation --testbed pour plus de détails. (ex : --testbed debian:bullseye)
11. Définissez le seuil pour la branche main, le banc d’essai debian:bullseye, et la mesure de latency :
    1. Définissez l’option --threshold-measure sur la mesure intégrée latency qui est générée par bencher mock. Consultez la documentation --threshold-measure pour plus de détails. (ex : --threshold-measure latency)
    2. Définissez l’option --threshold-test sur un test t de Student (t_test). Consultez la documentation --threshold-test pour un aperçu complet. (ex : --threshold-test t_test)
    3. Définissez l’option --threshold-max-sample-size sur la taille d’échantillon maximale de 64. Consultez la documentation --threshold-max-sample-size pour plus de détails. (ex : --threshold-max-sample-size 64)
    4. Définissez l’option --threshold-upper-boundary sur la limite supérieure de 0.99. Consultez la documentation --threshold-upper-boundary pour plus de détails. (ex : --threshold-upper-boundary 0.99)
    5. Définissez le flag --thresholds-reset pour que seul le seuil spécifié soit actif. Consultez la documentation --thresholds-reset pour un aperçu complet. (ex : --thresholds-reset)
12. Définissez le flag --err pour que la commande échoue si une alerte est générée. Consultez la documentation --err pour un aperçu complet. (ex : --err)
13. Définissez l’option --adapter sur le format JSON de Bencher Metric (json) Bencher Metric Format JSON (json) qui est généré par bencher mock. Consultez les adaptateurs de harnais de benchmark pour un aperçu complet. (ex : --adapter json)
14. Spécifiez les arguments de commande du benchmark. Consultez la commande du benchmark pour un aperçu complet. (ex : bencher mock)

Demandes de Fusion

Pour détecter une régression de performance dans les Demandes de Fusion, vous devrez exécuter vos benchmarks sur les MRs. L’exemple ci-dessous ne doit être utilisé que pour les branches au sein du même dépôt.

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. Mettez à jour le fichier GitLab CI/CD. (ex : .gitlab-ci.yml)
2. Créez un travail GitLab CI/CD. (ex : benchmark_mr_branch)
3. Exécutez si le pipeline a été déclenché par un merge_request_event. Consultez la documentation des règles GitLab CI/CD et la documentation des variables prédéfinies GitLab CI/CD pour un aperçu complet. (ex : rules: if: ...)
4. Définissez l’image dans laquelle le travail sera exécuté. Consultez la documentation des images GitLab CI/CD pour un aperçu complet. (ex : image: debian:bullseye)
5. Installez l’outil Bencher CLI en utilisant le script pratique. (ex : before_script: ...)
6. Utilisez la sous-commande CLI bencher run pour exécuter vos benchmarks de branche de demande de fusion. Consultez la sous-commande CLI bencher run pour un aperçu complet. (ex : bencher run)
7. Définissez l’option --project sur le slug du Projet. Consultez la documentation --project pour plus de détails. (ex : --project project-abc4567-wxyz123456789)
8. Définissez l’option --token sur la variable d’environnement masquée BENCHER_API_TOKEN. Consultez la documentation --token pour plus de détails. (ex : --token "$BENCHER_API_TOKEN")
9. Définissez l’option --branch sur le nom de la branche MR en utilisant une variable prédéfinie GitLab CI/CD. Consultez la documentation --branch pour un aperçu complet. (ex : --branch "$CI_COMMIT_REF_NAME")
10. Définissez le Point de Départ pour la Branchement MR :
    1. Définissez l’option --start-point sur le point de départ de la branche MR en utilisant une variable prédéfinie GitLab CI/CD. Consultez la documentation --start-point pour un aperçu complet. (ex : --start-point "$CI_MERGE_REQUEST_TARGET_BRANCH_NAME")
    2. Définissez l’option --start-point-hash sur le hash git du point de départ de la branche MR en utilisant une variable prédéfinie GitLab CI/CD. Consultez la documentation --start-point-hash pour un aperçu complet. (ex : --start-point-hash "$CI_MERGE_REQUEST_TARGET_BRANCH_SHA")
    3. Activez le drapeau --start-point-clone-thresholds pour cloner les Seuils du point de départ. Consultez la documentation --start-point-clone-thresholds pour un aperçu complet. (ex : --start-point-clone-thresholds)
    4. Activez le drapeau --start-point-reset pour toujours réinitialiser la Branche MR au point de départ. Cela empêchera la dérive des données des benchmarks. Consultez la documentation --start-point-reset pour un aperçu complet. (ex : --start-point-reset)
11. Définissez l’option --testbed sur le nom du banc d’essai. Cela devrait probablement correspondre à la machine sélectionnée dans image. Consultez la documentation --testbed pour plus de détails. (ex : --testbed debian:bullseye)
12. Activez le drapeau --err pour échouer à la commande si une alerte est générée. Consultez la documentation --err pour un aperçu complet. (ex : --err)
13. Définissez l’option --adapter sur Bencher Metric Format JSON (json) qui est généré par bencher mock. Consultez les adaptateurs de harnais de benchmark pour un aperçu complet. (ex : --adapter json)
14. Spécifiez les arguments de la commande benchmark. Consultez la commande benchmark pour un aperçu complet. (ex : bencher mock)

Pour nettoyer la branche MR après la fermeture de sa MR, vous pouvez créer un travail distinct qui interroge l’état de la MR en utilisant l’API GitLab. Si l’état est closed, ce travail archivera la branche MR en utilisant la commande 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 project-abc4567-wxyz123456789 \
        --token "$BENCHER_API_TOKEN" \
        --branch "$CI_COMMIT_REF_NAME"
      else
        echo 'Merge request is not `closed`. Skipping archival.'
      fi

1. Mettez à jour le fichier CI/CD de GitLab. (ex: .gitlab-ci.yml)
2. Créez un travail CI/CD de GitLab. (ex: archive_mr_branch)
3. Exécutez if le pipeline a été déclenché par un merge_request_event. Consultez la documentation des rules CI/CD de GitLab et la documentation des variables prédéfinies CI/CD de GitLab pour un aperçu complet. (ex: rules: if: ...)
4. Définissez l’image dans laquelle le travail s’exécutera. Consultez la documentation de l’image CI/CD de GitLab pour un aperçu complet. (ex: image: debian:bullseye)
5. Installez le Bencher CLI en utilisant le script de commodité. (ex: before_script: curl ...)
6. Vérifiez l’état de la MR via l’API GitLab. (ex: before_script: MR_STATE=$(...))
7. Utilisez la sous-commande CLI bencher archive pour archiver la branche MR si l’état de la MR est closed. (ex: bencher archive)
8. Définissez l’option --project sur le slug du projet. Consultez la documentation de l’option --project pour plus de détails. (ex: --project project-abc4567-wxyz123456789)
9. Définissez l’option --token sur la variable d’environnement masquée BENCHER_API_TOKEN. Consultez la documentation de l’option --token pour plus de détails. (ex: --token "$BENCHER_API_TOKEN")
10. Définissez l’option --branch sur le nom de la branche MR en utilisant une variable prédéfinie CI/CD de GitLab. (ex: --branch "$CI_COMMIT_REF_NAME")

🐰 Félicitations ! Vous avez appris à utiliser Bencher dans GitLab CI/CD ! 🎉

Continuez : Vue d’ensemble sur le Benchmarking ➡