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
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: bencherdev/bencher@main
      - name: Track base branch benchmarks with Bencher
        run: |
          bencher run \
          --project save-walter-white-1234abcd \
          --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 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)
5. Récupérez le code source de votre branche de base. (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 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)
8. Définissez l’option --project sur le slug du Projet. Consultez les documents --project pour plus de détails. (ex: --project save-walter-white-1234abcd)
9. 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 }}')
10. 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)
11. 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)
12. 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)
13. 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)
14. 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)
15. 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 }}')
16. Spécifiez les arguments de la commande de benchmark. Consultez la commande de benchmark pour un aperçu complet. (ex: bencher mock)

Pull Requests

Pour détecter les régressions de performance dans les demandes de tirage (Pull Requests), vous devez exécuter vos benchmarks sur les PRs. Si vous ne vous attendez à avoir des PRs de branches à l’intérieur du même dépôt, vous pouvez simplement créer un autre flux de travail pour exécuter on des événements 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 from 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 save-walter-white-1234abcd \
          --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 de workflow GitHub Actions. (ex : .github/workflows/pr_benchmarks.yml)

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

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

   Consultez la documentation sur on de GitHub Actions et la documentation sur pull_request de GitHub Actions 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 si et seulement si la demande de tirage provient du même dépôt. ⚠️ NE PAS SUPPRIMER CETTE LIGNE ! Pour gérer les Fork PRs, voir Pull Requests from 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 pull-requests. Selon vos paramètres GitHub, cela peut ne pas être requis. Mais pour tous 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 lequel le job s’exécutera. Consultez la documentation sur runs-on de GitHub Actions pour un aperçu complet. (ex : runs-on: ubuntu-latest)

7. Vérifiez 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 bencher run CLI pour exécuter vos benchmarks de branche de demande de tirage. Voir la sous-commande bencher run CLI pour un aperçu complet. (ex : bencher run)

10. Définissez l’option --project sur le slug du Projet. Voir les docs sur --project pour plus de détails. (ex : --project save-walter-white-1234abcd)

11. Définissez l’option --token sur le secret du Dépôt BENCHER_API_TOKEN. Voir les docs sur --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 le contexte github de GitHub Actions. Voir les docs sur --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 --start-point sur le point de départ de la branche PR en utilisant le contexte github de GitHub Actions. Voir les docs sur --start-point pour un aperçu complet. (ex : --start-point '${{ github.base_ref }}')
    2. Définissez --start-point-hash sur le git hash du point de départ de la branche PR en utilisant l’événement pull_request de GitHub Actions. Voir les docs sur --start-point-hash pour un aperçu complet. (ex : --start-point-hash '${{ github.event.pull_request.base.sha }}')
    3. Définissez le flag --start-point-clone-thresholds pour cloner les Seuils à partir du point de départ. Voir les docs sur --start-point-clone-thresholds pour un aperçu complet. (ex : --start-point-clone-thresholds)
    4. Définissez le flag --start-point-reset pour toujours réinitialiser la branche PR au point de départ. Cela permettra d’éviter la dérive des données de benchmark. Voir les docs sur --start-point-reset pour un aperçu complet. (ex : --start-point-reset)

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

15. Définissez le flag --err pour échouer si une alerte est générée. Voir les docs sur --err pour un aperçu complet. (ex : --err)

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

17. Définissez l’option --github-actions sur le token d’authentification API GitHub pour poster les résultats en tant que commentaire sur la demande de tirage en utilisant la variable d’environnement GITHUB_TOKEN de GitHub Actions. Voir les docs sur --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 de PR après la fermeture de sa PR, vous pouvez créer un workflow séparé pour s’exécuter on des événements pull_request avec le type closed. Ce workflow archivera la branche de la 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
    permissions:
      pull-requests: write
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: bencherdev/bencher@main
      - name: Archive closed PR branch with Bencher
        run: |
          bencher archive \
          --project save-walter-white-1234abcd \
          --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. S’exécuter sur les événements pull_request:

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

   Voir 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. S’exécuter sur les événements pull_request uniquement si la pull request provient du même dépôt. ⚠️ NE SUPPRIMEZ PAS CETTE LIGNE ! Pour le traitement des PRs provenant de Forks, voir Pull Requests depuis les Forks ci-dessous. (ex: if: github.event_name == 'pull_request' && github.event.pull_request.head.repo.full_name == github.repository)

5. Définissez les autorisations pour le GITHUB_TOKEN à write pour pull-requests. Selon vos paramètres GitHub, cela peut ne pas être nécessaire. Mais pour tous les organisations et dépôts personnels créés après le 02 février 2023, ceci 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 lequel le job s’exécutera. Voir la documentation GitHub Actions runs-on 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 archive pour archiver la branche PR. (ex: bencher archive)

10. Définissez l’option --project sur le slug du Projet. Voir les docs --project pour plus de détails. (ex: --project save-walter-white-1234abcd)

11. Définissez l’option --token sur le secret du dépôt BENCHER_API_TOKEN. Voir les docs --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 le contexte github des 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'
    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.number}/merge`);
            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 save-walter-white-1234abcd \
          --token '${{ secrets.BENCHER_API_TOKEN }}' \
          --branch '${{ env.PR_HEAD }}' \
          --start-point '${{ env.PR_BASE }}' \
          --start-point-hash '${{ env.PR_BASE_SHA }}' \
          --start-point-clone-thresholds \
          --start-point-reset \
          --testbed ubuntu-latest \
          --err \
          --adapter json \
          --github-actions '${{ secrets.GITHUB_TOKEN }}' \
          --ci-number '${{ env.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 second 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 GitHub Actions. (ex : jobs: track_fork_pr_branch)
5. Exécutez ce job uniquement si la conclusion du workflow précédent a été un succès en utilisant l’événement workflow_run de GitHub Actions. (ex : if: github.event.workflow_run.conclusion == 'success')
6. Définissez le type de machine sur laquelle le job s’exécutera. Consultez la documentation GitHub Actions runs-on pour un aperçu complet. (ex : runs-on: ubuntu-latest)
7. Configurez les résultats des benchmarks et les noms des fichiers d’objet d’événement pull_request en tant que variables d’environnement. (ex : env: ...)
8. Téléchargez les résultats des benchmarks en cache et l’événement pull_request en utilisant l’action GitHub action-download-artifact. (ex : uses: dawidd6/action-download-artifact@v6)
9. Exportez les données nécessaires de l’événement pull_request en tant que variables d’environnement. (ex : core.exportVariable(...))
10. Installez le Bencher CLI en utilisant l’Action GitHub. (ex : uses: bencherdev/bencher@main)
11. Utilisez la sous-commande CLI bencher run pour suivre vos benchmarks de branche de pull de fork. Consultez la sous-commande CLI le bencher run pour un aperçu complet. (ex : bencher run)
12. Définissez l’option --project sur le slug du projet. Consultez les docs --project pour plus de détails. (ex : --project save-walter-white-1234abcd)
13. Définissez l’option --token sur le secret Repository BENCHER_API_TOKEN. Consultez les docs --token pour plus de détails. (ex : --token '${{ secrets.BENCHER_API_TOKEN }}')
14. Définissez l’option --branch sur le nom de la branche PR de fork en utilisant [le contexte github de GitHub Actions][github actions context]. Consultez les docs --branch pour un aperçu complet. (ex : --branch '${{ env.PR_HEAD }}')
15. Définissez le Point de Départ pour la Branche PR de fork :
    1. Définissez l’option --start-point sur le point de départ de la Branche PR de fork en utilisant [le contexte github de GitHub Actions][github actions context]. Consultez les docs --start-point pour un aperçu complet. (ex : --start-point '${{ env.PR_BASE }}')
    2. Définissez l’option --start-point-hash sur le git hash du point de départ de la Branche PR de fork en utilisant l’événement pull_request de GitHub Actions. Consultez les docs --start-point-hash pour un aperçu complet. (ex : --start-point-hash '${{ env.PR_BASE_SHA }}')
    3. Définissez le drapeau --start-point-clone-thresholds pour cloner les Seuils à partir du point de départ. Consultez les docs --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 de fork au point de départ. Cela empêchera la dérive des données de benchmark. Consultez les docs --start-point-reset pour un aperçu complet. (ex : --start-point-reset)
16. Définissez l’option --testbed sur le nom du Testbed. Cela devrait probablement correspondre à la machine sélectionnée dans runs-on. Consultez les docs --testbed pour plus de détails. (ex : --testbed ubuntu-latest)
17. Définissez le drapeau --err pour échouer la commande si une Alerte est générée. Consultez les docs --err pour un aperçu complet. (ex : --err)
18. Définissez l’option --adapter sur le Format de Métadonnées Bencher JSON (json) généré par bencher mock. Consultez les adaptateurs de harnais de benchmark pour un aperçu complet. (ex : --adapter json)
19. Définissez l’option --github-actions sur le token d’authentification API GitHub pour publier les résultats en tant que commentaire sur le Pull Request en utilisant la variable d’environnement GITHUB_TOKEN de GitHub Actions. Consultez les docs --github-actions pour plus de détails. (ex : --github-actions '${{ secrets.GITHUB_TOKEN }}')
20. Définissez l’option --ci-number sur le numéro du pull request. Consultez les docs --ci-number pour plus de détails. (ex : --ci-number '${{ env.PR_NUMBER }}')
21. Définissez l’option --file sur le chemin d’accès du fichier de résultats de benchmark. Consultez la commande benchmark pour un aperçu complet. (ex : --file "$BENCHMARK_RESULTS")

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

on:
  pull_request:
    types: [closed]

jobs:
  archive_fork_pr_branch:
    name: Archive closed fork PR branch with Bencher
    permissions:
      pull-requests: write
    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 save-walter-white-1234abcd \
          --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 lors des événements pull_request :

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

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

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

4. Configurez les permissions pour le GITHUB_TOKEN à write pour 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. Consultez la documentation GitHub pour un aperçu complet. (ex : permissions: pull-requests: write)

5. 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)

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

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

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

9. Définissez l’option --project sur le slug du projet. Consultez la documentation --project pour plus de détails. (ex : --project save-walter-white-1234abcd)

10. Configurez l’option --token sur le secret Repository BENCHER_API_TOKEN. Consultez la documentation --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 le contexte github 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 ➡