Comment utiliser Bencher dans GitHub Actions

Depending on your use case, you can set up Continuous Benchmarking in GitHub Actions for your:

• Base Branch
• Pull Requests
• Pull Requests from Forks

Assurez-vous d’avoir créé un jeton API et de l’avoir défini comme un secret de Référentiel nommé BENCHER_API_TOKEN avant de continuer ! Allez à Votre Répo -> Paramètres -> Secrets et variables -> Actions -> Nouveau secret de référentiel. Nommez le secret BENCHER_API_TOKEN et définissez la valeur secrète sur votre jeton API.

Dans GitHub Actions, les secrets ne sont pas transmis au runner lorsqu’un workflow est déclenché depuis un dépôt forké. Par conséquent, vous devrez utiliser une branche du même dépôt lors de l’ajout de l’un des workflows ci-dessous à votre dépôt avec une pull request. Si vous essayez d’ajouter Bencher avec une pull request à partir d’un fork, alors le secret BENCHER_API_TOKEN ne sera pas disponible. ${{ secrets.BENCHER_API_TOKEN }} sera une chaîne vide.

Branche de Base

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

on:
  push:
    branches: main

jobs:
  benchmark_base_branch:
    name: Continuous Benchmarking with Bencher
    permissions:
      checks: write
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: bencherdev/bencher@main
      - name: Track base branch benchmarks with Bencher
        run: |
          bencher run \
          --project project-abc4567-wxyz123456789 \
          --token '${{ secrets.BENCHER_API_TOKEN }}' \
          --branch main \
          --testbed ubuntu-latest \
          --threshold-measure latency \
          --threshold-test t_test \
          --threshold-max-sample-size 64 \
          --threshold-upper-boundary 0.99 \
          --thresholds-reset \
          --err \
          --adapter json \
          --github-actions '${{ secrets.GITHUB_TOKEN }}' \
          bencher mock

1. Créez un fichier workflow GitHub Actions. (ex: .github/workflows/base_benchmarks.yml)
2. Exécutez sur les événements push vers la branche main. Consultez la documentation GitHub Actions on et la documentation GitHub Actions push pour un aperçu complet. (ex: on: push: branches: main)
3. Créez un job GitHub Actions. (ex: jobs: benchmark_base_branch)
4. Définissez les autorisations pour le GITHUB_TOKEN sur write pour checks. (ex : permissions: checks: write)
5. Définissez le type de machine sur laquelle le job sera exécuté. Consultez la documentation GitHub Actions runs-on pour un aperçu complet. (ex: runs-on: ubuntu-latest)
6. Récupérez le code source de votre branche de base. (ex: uses: actions/checkout@v4)
7. Installez le Bencher CLI en utilisant l’Action GitHub. (ex: uses: bencherdev/bencher@main)
8. 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)
9. Définissez l’option --project sur le slug du Projet. Consultez les documents --project pour plus de détails. (ex: --project project-abc4567-wxyz123456789)
10. Définissez l’option --token sur le secret Repository BENCHER_API_TOKEN. Consultez les documents --token pour plus de détails. (ex: --token '${{ secrets.BENCHER_API_TOKEN }}')
11. Définissez l’option --branch sur le nom de la branche de base. Consultez les documents --branch pour un aperçu complet. (ex: --branch main)
12. Réglez l’option --testbed sur le nom du Testbed. Cela devrait probablement correspondre à la machine sélectionnée dans runs-on. Consultez les documents --tested pour plus de détails. (ex: --testbed ubuntu-latest)
13. Définissez le seuil pour la Branche main, le Testbed ubuntu-latest, et la Mesure latency:
    1. Définissez l’option --threshold-measure sur la Mesure intégrée latency générée par bencher mock. Consultez les documents --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 les documents --threshold-test pour un aperçu complet. (ex: --threshold-test t_test)
    3. Définissez l’option --threshold-max-sample-size sur la taille maximale de l’échantillon de 64. Consultez les documents --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 les documents --threshold-upper-boundary pour plus de détails. (ex: --threshold-upper-boundary 0.99)
    5. Réglez l’indicateur --thresholds-reset pour que seul le seuil spécifié soit actif. Consultez les documents --thresholds-reset pour un aperçu complet. (ex: --thresholds-reset)
14. Réglez l’indicateur --err pour échouer la commande si une Alerte est générée. Consultez les documents --err pour un aperçu complet. (ex: --err)
15. 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)
16. Réglez l’option --github-actions sur le jeton d’authentification API GitHub pour publier les résultats sous forme de commentaire de Vérifications GitHub en utilisant la variable d’environnement GITHUB_TOKEN de GitHub Actions. Consultez les documents --github-actions pour plus de détails. (ex: --github-actions '${{ secrets.GITHUB_TOKEN }}')
17. Spécifiez les arguments de la commande de benchmark. Consultez la commande de benchmark pour un aperçu complet. (ex: bencher mock)

Pull Requests

Afin de détecter une régression de performance dans les Pull Requests, vous devrez exécuter vos benchmarks sur les PRs. Si vous vous attendez uniquement à recevoir des PRs à partir de branches au sein du même dépôt, alors vous pouvez simplement créer un autre workflow pour fonctionner avec des événements on pull_request du même dépôt.

⚠️ Cette solution ne fonctionne que si toutes les PRs proviennent du même dépôt ! Voir Pull Requests depuis des Forks ci-dessous.

on:
  pull_request:
    types: [opened, reopened, edited, synchronize]

jobs:
  benchmark_pr_branch:
    name: Continuous Benchmarking PRs with Bencher
    # DO NOT REMOVE: For handling Fork PRs see Pull Requests from Forks
    if: github.event_name == 'pull_request' && github.event.pull_request.head.repo.full_name == github.repository
    permissions:
      pull-requests: write
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: bencherdev/bencher@main
      - name: Track PR Benchmarks with Bencher
        run: |
          bencher run \
          --project project-abc4567-wxyz123456789 \
          --token '${{ secrets.BENCHER_API_TOKEN }}' \
          --branch "$GITHUB_HEAD_REF" \
          --start-point "$GITHUB_BASE_REF" \
          --start-point-hash '${{ github.event.pull_request.base.sha }}' \
          --start-point-clone-thresholds \
          --start-point-reset \
          --testbed ubuntu-latest \
          --err \
          --adapter json \
          --github-actions '${{ secrets.GITHUB_TOKEN }}' \
          bencher mock

1. Créez un fichier workflow GitHub Actions. (ex : .github/workflows/pr_benchmarks.yml)

2. Exécutez sur des événements pull_request :

   • opened - Une pull request a été créée.
   • reopened - Une pull request précédemment fermée a été rouverte.
   • edited - Le titre ou le corps d’une pull request a été modifié, ou la branche de base d’une pull request a été changée.
   • synchronize - La branche head d’une pull request a été mise à jour. Par exemple, la branche head a été mise à jour à partir de la branche de base ou de nouveaux commits ont été poussés à la branche head.

   Consultez la documentation de GitHub Actions on et la documentation de GitHub Actions pull_request pour un aperçu complet. (ex : on: pull_request: types: [opened, reopened, edited, synchronize])

3. Créez un job GitHub Actions. (ex : jobs: benchmark_pr_branch)

4. Exécutez sur des événements pull_request uniquement si la pull request vient du même dépôt. ⚠️ NE SUPPRIMEZ PAS CETTE LIGNE ! Pour gérer les PRs de Forks, voir Pull Requests depuis des Forks ci-dessous. (ex : if: github.event_name == 'pull_request' && github.event.pull_request.head.repo.full_name == github.repository)

5. Définissez les permissions pour le GITHUB_TOKEN sur write pour les pull-requests. Selon vos paramètres GitHub, cela peut ne pas être nécessaire. Mais pour toutes les organisations et dépôts personnels créés après le 02 février 2023, c’est le comportement par défaut. Voir la documentation GitHub pour un aperçu complet. (ex : permissions: pull-requests: write)

6. Définissez le type de machine sur laquelle le job s’exécutera. Voir la documentation runs-on de GitHub Actions pour un aperçu complet. (ex : runs-on: ubuntu-latest)

7. Validez le code source de la branche PR. (ex : uses: actions/checkout@v4)

8. Installez le Bencher CLI en utilisant l’Action GitHub. (ex : uses: bencherdev/bencher@main)

9. Utilisez la sous-commande CLI bencher run pour exécuter vos benchmarks de branche de pull request. Voir la sous-commande CLI bencher run pour un aperçu complet. (ex : bencher run)

10. Définissez l’option --project sur le slug du projet. Voir la documentation --project pour plus de détails. (ex : --project project-abc4567-wxyz123456789)

11. Définissez l’option --token sur le secret du dépôt BENCHER_API_TOKEN. Voir la documentation --token pour plus de détails. (ex : --token '${{ secrets.BENCHER_API_TOKEN }}')

12. Définissez l’option --branch sur le nom de la branche PR en utilisant la variable d’environnement par défaut GITHUB_HEAD_REF de GitHub Actions. Voir la documentation --branch pour un aperçu complet. (ex : --branch "$GITHUB_HEAD_REF")

13. Définissez le Point de Départ pour la branche PR :

    1. Définissez l’option --start-point sur le point de départ de la branche PR en utilisant la variable d’environnement par défaut GITHUB_BASE_REF de GitHub Actions. Voir la documentation --start-point pour un aperçu complet. (ex : --start-point "$GITHUB_BASE_REF")
    2. Définissez l’option --start-point-hash sur le hash git du point de départ de la branche PR en utilisant l’événement pull_request de GitHub Actions. Voir la documentation --start-point-hash pour un aperçu complet. (ex : --start-point-hash '${{ github.event.pull_request.base.sha }}')
    3. Définissez le drapeau --start-point-clone-thresholds pour cloner les Seuils à partir du point de départ. Voir la documentation --start-point-clone-thresholds pour un aperçu complet. (ex : --start-point-clone-thresholds)
    4. Définissez le drapeau --start-point-reset pour toujours réinitialiser la branche PR au point de départ. Cela empêchera la dérive des données de benchmark. Voir la documentation --start-point-reset pour un aperçu complet. (ex : --start-point-reset)

14. Définissez l’option --testbed sur le nom du Banc d’Essai. Cela devrait probablement correspondre à la machine sélectionnée dans runs-on. Voir la documentation --testbed pour plus de détails. (ex : --testbed ubuntu-latest)

15. Définissez le drapeau --err pour échouer la commande si une Alerte est générée. Voir la documentation --err pour un aperçu complet. (ex : --err)

16. Définissez l’option --adapter sur le Format de Métrique Bencher JSON (json) généré par bencher mock. Voir les adaptateurs de harnais de benchmark pour un aperçu complet. (ex : --adapter json)

17. Définissez l’option --github-actions sur le token d’authentification de l’API GitHub pour poster les résultats en tant que commentaire sur la Pull Request en utilisant la variable d’environnement GITHUB_TOKEN de GitHub Actions. Voir la documentation --github-actions pour plus de détails. (ex : --github-actions '${{ secrets.GITHUB_TOKEN }}')

18. Spécifiez les arguments de commande de benchmark. Voir la commande de benchmark pour un aperçu complet. (ex : bencher mock)

Pour nettoyer la branche PR après la fermeture de la PR, vous pouvez créer un flux de travail séparé pour s’exécuter on des événements pull_request avec le type closed. Ce flux de travail archivera la branche PR en utilisant la commande bencher archive.

on:
  pull_request:
    types: [closed]

jobs:
  archive_pr_branch:
    name: Archive closed PR branch with Bencher
    # DO NOT REMOVE: For handling Fork PRs see Pull Requests from Forks
    if: github.event_name == 'pull_request' && github.event.pull_request.head.repo.full_name == github.repository
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: bencherdev/bencher@main
      - name: Archive closed PR branch with Bencher
        run: |
          bencher archive \
          --project project-abc4567-wxyz123456789 \
          --token '${{ secrets.BENCHER_API_TOKEN }}' \
          --branch "$GITHUB_HEAD_REF"

1. Créez un fichier workflow GitHub Actions. (ex: .github/workflows/pr_benchmarks_closed.yml)

2. Exécutez sur les événements pull_request :

   • closed - Une pull request a été fermée.

   Consultez la documentation GitHub Actions on et la documentation GitHub Actions pull_request pour un aperçu complet. (ex: on: pull_request: types: [closed])

3. Créez un job GitHub Actions. (ex: jobs: archive_pr_branch)

4. Exécutez sur les événements pull_request uniquement si la pull request provient du même dépôt. ⚠️ NE PAS SUPPRIMER CETTE LIGNE ! Pour gérer les PRs de fork, voir Pull Requests de Forks ci-dessous. (ex: if: github.event_name == 'pull_request' && github.event.pull_request.head.repo.full_name == github.repository)

5. Définissez le type de machine sur lequel le job s’exécutera. Voir la documentation runs-on GitHub Actions pour un aperçu complet. (ex: runs-on: ubuntu-latest)

6. Validez le code source de la branche PR. (ex: uses: actions/checkout@v4)

7. Installez le Bencher CLI en utilisant l’Action GitHub. (ex: uses: bencherdev/bencher@main)

8. Utilisez la sous-commande CLI bencher archive pour archiver la branche PR. (ex: bencher archive)

9. Configurez l’option --project sur le slug du projet. Consultez les documents --project pour plus de détails. (ex: --project project-abc4567-wxyz123456789)

10. Configurez l’option --token avec le secret du Dépôt BENCHER_API_TOKEN. Consultez les documents --token pour plus de détails. (ex: --token '${{ secrets.BENCHER_API_TOKEN }}')

11. Configurez l’option --branch sur le nom de la branche PR en utilisant la variable d’environnement par défaut GITHUB_HEAD_REF de GitHub Actions. (ex: --branch "$GITHUB_HEAD_REF")

Demandes de Tirage depuis des Fourches

Si vous envisagez d’accepter des demandes de tirage depuis des fourches, comme c’est souvent le cas dans les projets open source publics, alors vous devrez gérer les choses un peu différemment. Pour des raisons de sécurité, des secrets tels que votre BENCHER_API_TOKEN et le GITHUB_TOKEN ne sont pas disponibles dans les GitHub Actions pour les PRs de fourches. Ainsi, si un contributeur externe ouvre une PR depuis une fourche, l’exemple ci-dessus ne fonctionnera pas. Consultez cette analyse de GitHub Security Lab et cet article de blog sur la prévention des pwn requests pour un aperçu complet.

Voici la manière sûre et suggérée pour ajouter le benchmarking continu aux demandes de tirage de fourches. Cela nécessite deux workflows distincts. Le premier workflow exécute et met en cache les résultats du benchmark dans le contexte pull_request. Aucun secret tel que votre BENCHER_API_TOKEN et le GITHUB_TOKEN n’y est disponible. Ensuite, un second workflow télécharge les résultats des benchmarks mis en cache dans le contexte workflow_run et les télécharge vers Bencher. Cela fonctionne car workflow_run s’exécute dans le contexte de la branche par défaut du dépôt, où des secrets tels que votre BENCHER_API_TOKEN et le GITHUB_TOKEN sont disponibles. Le numéro de la demande de tirage, la branche principale et la branche de base utilisées dans le workflow initial pull_request doivent également être explicitement passés dans le workflow workflow_run car ils ne sont pas disponibles là-bas. Ces workflows ne s’exécuteront que s’ils existent sur la branche par défaut. Voir utilisation des données du workflow déclencheur pour un aperçu complet.

name: Run Benchmarks

on:
  pull_request:
    types: [opened, reopened, edited, synchronize]

jobs:
  benchmark_fork_pr_branch:
    name: Run Fork PR Benchmarks
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Mock Benchmarking
        run: |
          /bin/echo '{ "bencher::mock_0": { "latency": { "value": 1.0 } } }' > benchmark_results.json
      - name: Upload Benchmark Results
        uses: actions/upload-artifact@v4
        with:
          name: benchmark_results.json
          path: ./benchmark_results.json
      - name: Upload GitHub Pull Request Event
        uses: actions/upload-artifact@v4
        with:
          name: event.json
          path: ${{ github.event_path }}

1. Créez un premier fichier workflow GitHub Actions. (ex : .github/workflows/fork_pr_benchmarks_run.yml)

2. Nommez ce workflow afin qu’il puisse être référencé par le deuxième workflow. (ex : name: Run Benchmarks)

3. Exécutez sur les événements pull_request :

   • opened - Une pull request a été créée.
   • reopened - Une pull request précédemment fermée a été réouverte.
   • edited - Le titre ou le corps d’une pull request a été modifié, ou la branche de base d’une pull request a été changée.
   • synchronize - La branche head d’une pull request a été mise à jour. Par exemple, la branche head a été mise à jour à partir de la branche de base ou de nouveaux commits ont été poussés vers la branche head.

   Voir la documentation GitHub Actions on et la documentation GitHub Actions pull_request pour un aperçu complet. (ex : on: pull_request: types: [opened, reopened, edited, synchronize])

4. Créez un job GitHub Actions. (ex : jobs: benchmark_fork_pr_branch)

5. Définissez le type de machine sur lequel le job s’exécutera. Voir la documentation GitHub Actions runs-on pour un aperçu complet. (ex : runs-on: ubuntu-latest)

6. Récupérez le code source de la branche fork PR. (ex : uses: actions/checkout@v4)

7. Exécutez vos benchmarks et enregistrez les résultats dans un fichier. (ex : /bin/echo '{ ... }' > benchmark_results.json)

8. Téléchargez le fichier de résultats des benchmarks en tant qu’artifact. (ex : uses: actions/upload-artifact@v4)

9. Téléchargez l’objet d’événement pull_request en tant qu’artifact. (ex : uses: actions/upload-artifact@v4)

name: Track Benchmarks with Bencher

on:
  workflow_run:
    workflows: [Run Benchmarks]
    types: [completed]

jobs:
  track_fork_pr_branch:
    if: github.event.workflow_run.conclusion == 'success'
    permissions:
      pull-requests: write
    runs-on: ubuntu-latest
    env:
      BENCHMARK_RESULTS: benchmark_results.json
      PR_EVENT: event.json
    steps:
      - name: Download Benchmark Results
        uses: dawidd6/action-download-artifact@v6
        with:
          name: ${{ env.BENCHMARK_RESULTS }}
          run_id: ${{ github.event.workflow_run.id }}
      - name: Download PR Event
        uses: dawidd6/action-download-artifact@v6
        with:
          name: ${{ env.PR_EVENT }}
          run_id: ${{ github.event.workflow_run.id }}
      - name: Export PR Event Data
        uses: actions/github-script@v6
        with:
          script: |
            let fs = require('fs');
            let prEvent = JSON.parse(fs.readFileSync(process.env.PR_EVENT, {encoding: 'utf8'}));
            core.exportVariable("PR_HEAD", prEvent.pull_request.head.ref);
            core.exportVariable("PR_HEAD_SHA", prEvent.pull_request.head.sha);
            core.exportVariable("PR_BASE", prEvent.pull_request.base.ref);
            core.exportVariable("PR_BASE_SHA", prEvent.pull_request.base.sha);
            core.exportVariable("PR_NUMBER", prEvent.number);
      - uses: bencherdev/bencher@main
      - name: Track Benchmarks with Bencher
        run: |
          bencher run \
          --project project-abc4567-wxyz123456789 \
          --token '${{ secrets.BENCHER_API_TOKEN }}' \
          --branch "$PR_HEAD" \
          --hash "$PR_HEAD_SHA" \
          --start-point "$PR_BASE" \
          --start-point-hash "$PR_BASE_SHA" \
          --start-point-clone-thresholds \
          --start-point-reset \
          --testbed ubuntu-latest \
          --err \
          --adapter json \
          --github-actions '${{ secrets.GITHUB_TOKEN }}' \
          --ci-number "$PR_NUMBER" \
          --file "$BENCHMARK_RESULTS"

1. Créez un premier fichier workflow GitHub Actions. (ex: .github/workflows/fork_pr_benchmarks_track.yml)
2. Nommez ce workflow deuxième workflow. (ex: name: Track Benchmarks with Bencher)
3. Chainez les deux workflows avec l’événement workflow_run. (ex: on: workflow_run: ...)
4. Créez un job pour GitHub Actions. (ex: jobs: track_fork_pr_branch)
5. Exécutez ce job uniquement si la conclusion du workflow précédent était un succès en utilisant l’événement workflow_run de GitHub Actions. (ex: if: github.event.workflow_run.conclusion == 'success')
6. Définissez les permissions pour le GITHUB_TOKEN sur write pour pull-requests. Selon vos paramètres GitHub, cela peut ne pas être nécessaire. Mais pour toutes les organisations et les dépôts personnels créés après le 02 février 2023, ceci est le comportement par défaut. Consultez la documentation GitHub pour un aperçu complet. (ex: permissions: pull-requests: write)
7. Définissez le type de machine sur lequel le job sera exécuté. Consultez la documentation runs-on de GitHub Actions pour un aperçu complet. (ex: runs-on: ubuntu-latest)
8. Définissez les noms des fichiers de résultats de benchmark et de l’objet pull_request comme variables d’environnement. (ex: env: ...)
9. Téléchargez les résultats de benchmark mis en cache et l’événement pull_request en utilisant l’Action GitHub action-download-artifact. (ex: uses: dawidd6/action-download-artifact@v6)
10. Exportez les données nécessaires de l’événement pull_request en tant que variables d’environnement intermédiaires. (ex: core.exportVariable(...))
11. Installez le Bencher CLI en utilisant l’Action GitHub. (ex: uses: bencherdev/bencher@main)
12. Utilisez la sous-commande CLI bencher run pour suivre vos benchmarks de branche de pull request forkée. Consultez la sous-commande CLI bencher run pour un aperçu complet. (ex: bencher run)
13. Définissez l’option --project sur le slug du Projet. Consultez les documents --project pour plus de détails. (ex: --project project-abc4567-wxyz123456789)
14. Définissez l’option --token sur le secret Repository BENCHER_API_TOKEN. Consultez les documents --token pour plus de détails. (ex: --token '${{ secrets.BENCHER_API_TOKEN }}')
15. Définissez l’option --branch sur le nom de la branche PR forkée en utilisant une variable d’environnement intermédiaire. Consultez les documents --branch pour un aperçu complet. (ex: --branch "$PR_HEAD")
16. Définissez l’option --hash sur le hash git de la branche PR forkée en utilisant une variable d’environnement intermédiaire. Consultez les documents --hash pour un aperçu complet. (ex: --hash "$PR_HEAD_SHA")
17. Définissez le point de départ pour la branche PR forkée :
    1. Définissez l’option --start-point sur le point de départ de la branche PR forkée en utilisant une variable d’environnement intermédiaire. Consultez les documents --start-point pour un aperçu complet. (ex: --start-point "$PR_BASE")
    2. Définissez l’option --start-point-hash sur le hash git du point de départ de la branche PR forkée en utilisant une variable d’environnement intermédiaire. Consultez les documents --start-point-hash pour un aperçu complet. (ex: --start-point-hash "$PR_BASE_SHA")
    3. Définissez l’option --start-point-clone-thresholds pour cloner les seuils à partir du point de départ. Consultez les documents --start-point-clone-thresholds pour un aperçu complet. (ex: --start-point-clone-thresholds)
    4. Définissez l’option --start-point-reset pour toujours réinitialiser la branche PR forkée au point de départ. Cela empêchera la dérive des données de benchmark. Consultez les documents --start-point-reset pour un aperçu complet. (ex: --start-point-reset)
18. Définissez l’option --testbed sur le nom de l’environnement de test. Cela devrait probablement correspondre à la machine sélectionnée dans runs-on. Consultez les documents --tested pour plus de détails. (ex: --testbed ubuntu-latest)
19. Définissez le drapeau --err pour échouer la commande si une alerte est générée. Consultez les documents --err pour un aperçu complet. (ex: --err)
20. Définissez l’option --adapter sur le format JSON du Bencher Metric Format (json) généré par bencher mock. Consultez les adapters de harness de benchmark pour un aperçu complet. (ex: --adapter json)
21. Définissez l’option --github-actions sur le jeton d’authentification de l’API GitHub pour publier les résultats sous forme de commentaire sur la Pull Request en utilisant la variable d’environnement GITHUB_TOKEN de GitHub Actions. Consultez les documents --github-actions pour plus de détails. (ex: --github-actions '${{ secrets.GITHUB_TOKEN }}')
22. Définissez l’option --ci-number sur le numéro de pull request en utilisant une variable d’environnement intermédiaire. Consultez les documents --ci-number pour plus de détails. (ex: --ci-number "$PR_NUMBER")
23. Définissez l’option --file sur le chemin du fichier des résultats de benchmark. Consultez les commandes de benchmark pour un aperçu complet. (ex: --file "$BENCHMARK_RESULTS")

Pour nettoyer la branche de PR fork après la fermeture de sa PR, vous pouvez créer un flux de travail séparé pour s’exécuter lors des événements on pull_request_target de type closed. Ce flux de travail archivera la branche de PR fork en utilisant la commande bencher archive.

on:
  pull_request_target:
    types: [closed]

jobs:
  archive_fork_pr_branch:
    name: Archive closed fork PR branch with Bencher
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: bencherdev/bencher@main
      - name: Archive closed fork PR branch with Bencher
        run: |
          bencher archive \
          --project project-abc4567-wxyz123456789 \
          --token '${{ secrets.BENCHER_API_TOKEN }}' \
          --branch "$GITHUB_HEAD_REF"

1. Créez un fichier de workflow GitHub Actions. (ex : .github/workflows/fork_pr_benchmarks_closed.yml)

2. Exécutez sur les événements pull_request_target :

   • closed - Une pull request a été fermée.

   Consultez la documentation on de GitHub Actions et la documentation pull_request_target de GitHub Actions pour un aperçu complet. (ex : on: pull_request_target: types: [closed])

3. Créez un job GitHub Actions. (ex : jobs: archive_pr_branch)

4. Définissez le type de machine sur laquelle le job s’exécutera. Consultez la documentation runs-on de GitHub Actions pour un aperçu complet. (ex : runs-on: ubuntu-latest)

5. Récupérez le code source de la branche PR. (ex : uses: actions/checkout@v4)

6. Installez le Bencher CLI en utilisant l’action GitHub. (ex : uses: bencherdev/bencher@main)

7. Utilisez la sous-commande CLI bencher archive pour archiver la branche PR. (ex : bencher archive)

8. Définissez l’option --project avec 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 avec le secret de Repository BENCHER_API_TOKEN. Consultez la documentation de l’option --token pour plus de détails. (ex : --token '${{ secrets.BENCHER_API_TOKEN }}')

10. Définissez l’option --branch avec le nom de la branche PR en utilisant la variable d’environnement par défaut GITHUB_HEAD_REF de GitHub Actions. (ex : --branch "$GITHUB_HEAD_REF")

🐰 Félicitations ! Vous avez appris comment utiliser Bencher dans GitHub Actions ! 🎉

Continuez : Vue d’ensemble du Benchmarking ➡