Comment utiliser Bencher dans GitHub Actions

Selon votre cas d’usage, vous pouvez configurer le benchmarking continu dans GitHub Actions pour votre :

• Branche de base
• Demandes de tirage (Pull Requests)
• Demandes de tirage à partir de Forks
  • ⛑️ Plus sûr : Benchmark Fork PR et Upload depuis la Branche par Défaut
  • ⚠️ Plus risqué : Benchmark Fork PR depuis la Branche Cible avec Réviseurs Requis

🐰 Assurez-vous d’avoir créé un jeton d’API et de l’avoir défini comme un secret de dépôt (Repository) nommé BENCHER_API_TOKEN avant de continuer ! Naviguez vers Votre dépôt -> Paramètres -> Secrets et variables -> Actions -> Nouveau secret de dépôt. Nommez le secret BENCHER_API_TOKEN et définissez la valeur du secret à votre jeton d’API.

Branche de Base

Un pilier du Benchmarking Continu Statistique est d’avoir une ligne de base historique pour votre branche de base. Cette ligne de base historique peut ensuite ê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 \
          --adapter json \
          --err \
          bencher mock

1. Créer un fichier workflow GitHub Actions. (ex : .github/workflows/base_benchmarks.yml)
2. Exécuter lors des événements push vers la branche main. Voir la documentation GitHub Actions on et GitHub Actions push pour un aperçu complet. (ex : on: push: branches: main)
3. Créer un job GitHub Actions. (ex : jobs: benchmark_base_branch)
4. Définir le type de machine sur lequel le job sera exécuté. Voir la documentation GitHub Actions runs-on pour un aperçu complet. (ex : runs-on: ubuntu-latest)
5. Extraire le code source de votre branche de base. (ex : uses: actions/checkout@v4)
6. Installer le CLI Bencher en utilisant l’action GitHub. (ex : uses: bencherdev/bencher@main)
7. Utiliser la sous-commande CLI bencher run pour exécuter les benchmarks de votre branche main. Voir la sous-commande CLI bencher run pour un aperçu complet. (ex : bencher run)
8. Définir l’option --project sur le slug du projet. Voir la documentation --project pour plus de détails. (ex : --project save-walter-white-1234abcd)
9. Définir l’option --token sur le secret Repository BENCHER_API_TOKEN. Voir la documentation --token pour plus de détails. (ex : --token '${{ secrets.BENCHER_API_TOKEN }}')
10. Définir l’option --branch sur le nom de la branche. Voir la sélection de branche pour un aperçu complet. (ex : --branch main)
11. Définir 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)
12. Définir l’option --adapter sur l’adaptateur de harnais de benchmark souhaité. Voir les adaptateurs de harnais de benchmark pour un aperçu complet. (ex : --adapter json)
13. Définir le drapeau --err pour échouer la commande si une alerte est générée. Voir Seuils & Alertes pour un aperçu complet. (ex : --err)
14. Spécifier les arguments de la commande de benchmark. Voir commande de benchmark pour un aperçu complet. (ex : bencher mock)

Demandes de Tirage (Pull Requests)

Afin de détecter les régressions de performance dans les Demandes de Tirage, vous aurez besoin d’exécuter vos benchmarks sur les PRs. Si vous attendez uniquement des PRs provenant de branches du même dépôt, alors vous pouvez simplement créer un autre workflow pour exécuter on les événements pull_request provenant du même dépôt.

⚠️ Cette solution fonctionne uniquement si toutes les PRs proviennent du même dépôt ! Voir Demandes de Tirage 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 save-walter-white-1234abcd \
          --token '${{ secrets.BENCHER_API_TOKEN }}' \
          --branch '${{ github.head_ref }}' \
          --branch-start-point '${{ github.base_ref }}' \
          --branch-start-point-hash '${{ github.event.pull_request.base.sha }}' \
          --testbed ubuntu-latest \
          --adapter json \
          --err \
          --github-actions '${{ secrets.GITHUB_TOKEN }}' \
          bencher mock

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

2. Exécutez on les é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é édité, ou la branche de base d’une demande de tirage a été changée.
   • synchronize - La branche ‘head’ d’une demande de tirage a été mise à jour. Par exemple, la branche ‘head’ a été mise à jour depuis la branche de base ou de nouveaux commits ont été poussés vers la branche ‘head’.

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

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

4. Exécutez on les événements pull_request si et seulement si la demande de tirage provient du même dépôt. ⚠️ NE SUPPRIMEZ PAS CETTE LIGNE ! Pour gérer les PRs de Forks, voir Demandes de Tirage 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 à write pour pull-requests. Selon vos paramètres GitHub, cela peut ne pas être requis. Mais pour toutes les organisations et les repos 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 sera exécuté. Voir la documentation runs-on GitHub Actions pour un aperçu complet. (ex : runs-on: ubuntu-latest)

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

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

9. Utilisez la sous-commande CLI bencher run pour exécuter les benchmarks de votre branche de demande de tirage. 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 save-walter-white-1234abcd)

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 le contexte GitHub Actions github. Voir la sélection de branche pour un aperçu complet. (ex : --branch '${{ github.head_ref }}')

13. Définissez l’option --branch-start-point sur le point de départ de la branche de base PR en utilisant le contexte GitHub Actions github. Voir le point de départ de la sélection de branche pour un aperçu complet. (ex : --branch-start-point '${{ github.base_ref }}')

14. Définissez l’option --branch-start-point-hash sur le hash du point de départ de la branche de base PR en utilisant l’événement GitHub Actions pull_request. Voir le hash du point de départ de la sélection de branche pour un aperçu complet. (ex : --branch-start-point-hash '${{ github.event.pull_request.base.sha }}')

15. Définissez l’option --testbed sur le nom du Testbed. 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)

16. Définissez l’option --adapter sur l’adaptateur de harnais de benchmarks désiré. Voir les adaptateurs de harnais de benchmarks pour un aperçu complet. (ex : --adapter json)

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

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

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

Les Pull Requests provenant de Forks

Si vous prévoyez d’accepter les pull requests provenant de forks, 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é, les secrets tels que votre BENCHER_API_TOKEN et le GITHUB_TOKEN ne sont pas disponibles dans GitHub Actions pour les PR de forks. C’est-à-dire que si un contributeur externe ouvre une PR à partir d’un fork, l’exemple ci-dessus ne fonctionnera pas. Il y a deux options pour les PR de forks :

• ⛑️ Plus sûr : Benchmark Fork PR et Téléversement depuis la Branche par Défaut
• ⚠️ Plus risqué : Benchmark Fork PR depuis la Branche Cible avec des Réviseurs Requis

Voir ce rapport du GitHub Security Lab et ce billet de blog sur la prévention des pwn requests pour un aperçu complet.

Benchmark de PR Fork et Upload depuis la Branche par Défaut

Ceci est la manière sûre et suggérée d’ajouter un Benchmarking Continu aux pull requests des forks. Cela nécessite deux workflows séparés. Le premier workflow exécute et met en cache les résultats des benchmarks dans le contexte pull_request. Aucun secret tel que votre BENCHER_API_TOKEN et le GITHUB_TOKEN ne sont disponibles là. Ensuite, un second workflow télécharge les résultats des benchmarks mis en cache dans le contexte workflow_run et les téléverse à Bencher. Cela fonctionne parce que workflow_run s’exécute dans le contexte de la branche par défaut du dépôt, où les secrets comme votre BENCHER_API_TOKEN et le GITHUB_TOKEN sont disponibles. Le numéro de la pull request, la branche de tête et la branche de base utilisés dans le workflow pull_request initial doivent également être explicitement transmis au workflow workflow_run car ils ne sont pas disponibles là. Ces workflows ne s’exécuteront que s’ils sont présents sur la branche par défaut. Voir utiliser les données du workflow déclencheur pour un aperçu complet.

name: Run and Cache 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/run_fork_pr_benchmarks.yml)

2. Nommez ce workflow pour qu’il puisse être référencé par le second workflow. (ex: name: Exécuter et Mettre en Cache les Benchmarks)

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

   • opened - Une pull request a été créée.
   • reopened - Une pull request fermée précédemment 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 de tête d’une pull request a été mise à jour. Par exemple, la branche de tête a été mise à jour depuis la branche de base ou de nouveaux commits ont été poussés vers la branche de tête.

   Voir la documentation GitHub Actions on et 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 sera exécuté. 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 de la PR fork. (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éversez le fichier des résultats des benchmarks en tant qu’artefact. (ex: uses: actions/upload-artifact@v4)

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

name: Track Benchmarks with Bencher

on:
  workflow_run:
    workflows: [Run and Cache 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: actions/github-script@v6
        with:
          script: |
            async function downloadArtifact(artifactName) {
              let allArtifacts = await github.rest.actions.listWorkflowRunArtifacts({
                owner: context.repo.owner,
                repo: context.repo.repo,
                run_id: context.payload.workflow_run.id,
              });
              let matchArtifact = allArtifacts.data.artifacts.filter((artifact) => {
                return artifact.name == artifactName
              })[0];
              if (!matchArtifact) {
                core.setFailed(`Failed to find artifact: ${artifactName}`);
              }
              let download = await github.rest.actions.downloadArtifact({
                owner: context.repo.owner,
                repo: context.repo.repo,
                artifact_id: matchArtifact.id,
                archive_format: 'zip',
              });
              let fs = require('fs');
              fs.writeFileSync(`${process.env.GITHUB_WORKSPACE}/${artifactName}.zip`, Buffer.from(download.data));
            }
            await downloadArtifact(process.env.BENCHMARK_RESULTS);
            await downloadArtifact(process.env.PR_EVENT);
      - name: Unzip Benchmark Results
        run: |
          unzip $BENCHMARK_RESULTS.zip
          unzip $PR_EVENT.zip
      - 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 }}' \
          --branch-start-point '${{ env.PR_BASE }}' \
          --branch-start-point-hash '${{ env.PR_BASE_SHA }}' \
          --testbed ubuntu-latest \
          --adapter json \
          --err \
          --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/track_fork_pr_benchmarks.yml)
2. Nommez ce workflow second workflow. (ex: name: Suivre les Benchmarks avec Bencher)
3. Chaînez 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 travail uniquement si la conclusion du workflow précédent était un succès en utilisant l’événement GitHub Actions workflow_run. (ex: if: github.event.workflow_run.conclusion == 'success')
6. Définissez le type de machine sur lequel le job sera exécuté. Voir la documentation GitHub Actions runs-on pour un aperçu complet. (ex: runs-on: ubuntu-latest)
7. Définissez les noms de fichiers des résultats des benchmarks et de l’objet de l’événement pull_request comme variables d’environnement. (ex: env: ...)
8. Téléchargez les résultats des benchmarks mis en cache et l’événement pull_request. (ex: uses: actions/github-script@v6)
9. Extrayez les résultats des benchmarks mis en cache et l’événement pull_request. (ex: unzip ...)
10. Exportez les données nécessaires de l’événement pull_request en tant que variables d’environnement. (ex: core.exportVariable(...))
11. Installez le CLI Bencher en utilisant l’action GitHub. (ex: uses: bencherdev/bencher@main)
12. Utilisez la sous-commande CLI bencher run pour suivre les benchmarks de votre branche de pull request fork. Voir 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. Voir la documentation de l’option --project pour plus de détails. (ex: --project save-walter-white-1234abcd)
14. Définissez l’option --token sur le secret Repository BENCHER_API_TOKEN. Voir la documentation de l’option --token pour plus de détails. (ex: --token '${{ secrets.BENCHER_API_TOKEN }}')
15. Définissez l’option --branch sur le numéro formaté de la PR fork en utilisant l’événement GitHub Actions pull_request. Voir la sélection de la branche pour un aperçu complet. (ex: --branch '${{ env.PR_HEAD }}')
16. Définissez l’option --branch-start-point sur le point de départ de la branche de base de la PR fork en utilisant l’événement GitHub Actions pull_request. Voir la sélection du point de départ de la branche pour un aperçu complet. (ex: --branch-start-point '${{ env.PR_BASE }}')
17. Définissez l’option --branch-start-point-hash sur le hash du point de départ de la branche de base de la PR fork en utilisant l’événement GitHub Actions pull_request. Voir la sélection du hash du point de départ de la branche pour un aperçu complet. (ex: --branch-start-point-hash '${{ env.PR_BASE_SHA }}')
18. 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 de l’option --testbed pour plus de détails. (ex: --testbed ubuntu-latest)
19. Définissez l’option --adapter sur l’adaptateur de harnais de benchmarks souhaité. Voir les adaptateurs de harnais de benchmarks pour un aperçu complet. (ex: --adapter json)
20. Définissez le drapeau --err pour faire échouer la commande si une alerte est générée. Voir Seuil & Alertes pour un aperçu complet. (ex: --err)
21. Définissez l’option --github-actions sur le jeton d’authentification de l’API GitHub pour publier les résultats en tant que commentaire sur la Pull Request en utilisant la variable d’environnement GitHub Actions GITHUB_TOKEN. Voir la documentation de l’option --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 la pull request. Voir la documentation de l’option --ci-number pour plus de détails. (ex: --ci-number '${{ env.PR_NUMBER }}')
23. Définissez l’option --file sur le chemin du fichier des résultats des benchmarks. Voir la commande de benchmark pour un aperçu complet. (ex: --file "$BENCHMARK_RESULTS")

Comparer les PR de forks avec la branche cible et avec des réviseurs requis

Afin de garantir que le code provenant d’une pull request de fork est sécurisé, cette Action GitHub vérifie si le fork provient d’un autre dépôt. Si le fork provient d’un autre dépôt, alors il devra être révisé.

⚠️ Il est très, très important de réviser minutieusement chaque PR de fork avant approbation ! Ne pas le faire pourrait résulter en une demande de piratage !

Si vous préférez ne pas avoir cela sur la conscience, voir [Comparer les PR de forks et télécharger depuis la branche par défaut][benchmark fork pr and upload from default branch] ci-dessus.

Pour configurer ce workflow, vous devez créer deux [environnements GitHub Actions][github actions environments]. Naviguez vers Votre dépôt -> Paramètres -> Environnements -> Nouvel environnement. Créez deux nouveaux environnements, interne et externe. L’environnement interne ne devrait avoir aucune Règle de protection de déploiement. Cependant, l’environnement externe devrait avoir des Réviseurs requis définis pour ceux ayant la confiance de réviser les PR de forks avant d’effectuer des benchmarks. Voir [ce billet de blog][iterative.ai blog] pour un aperçu complet.

Cette configuration fonctionne car pull_request_target s’exécute dans le contexte de la branche cible de la pull request, où des secrets tels que votre BENCHER_API_TOKEN et le GITHUB_TOKEN sont disponibles. Par conséquent, ce workflow ne s’exécutera que s’il existe sur la branche cible. Evitez de définir des secrets comme variables d’environnement, tels que GITHUB_TOKEN et BENCHER_API_TOKEN. Passez plutôt explicitement vos secrets à bencher run.

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

jobs:
  fork_pr_requires_review:
    environment: ${{ (github.event.pull_request.head.repo.full_name == github.repository && 'internal') || 'external' }}
    runs-on: ubuntu-latest
    steps:
      - run: true

  benchmark_fork_pr_branch:
    needs: fork_pr_requires_review
    name: Continuous Benchmarking Fork PRs with Bencher
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          repository: ${{ github.event.pull_request.head.repo.full_name }}
          ref: ${{ github.event.pull_request.head.sha }}
          persist-credentials: false
      - uses: bencherdev/bencher@main
      - name: Track Fork PR Benchmarks with Bencher
        run: |
          bencher run \
          --project save-walter-white-1234abcd \
          --token '${{ secrets.BENCHER_API_TOKEN }}' \
          --branch '${{ github.event.number }}/merge' \
          --branch-start-point '${{ github.base_ref }}' \
          --branch-start-point-hash '${{ github.event.pull_request.base.sha }}' \
          --testbed ubuntu-latest \
          --adapter json \
          --err \
          --github-actions '${{ secrets.GITHUB_TOKEN }}' \
          bencher mock

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

2. 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é 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 tête d’une pull request 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 sur la branche tête.

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

3. Créez un premier job GitHub Actions pour vérifier si le workflow requiert une révision. (ex : jobs: fork_pr_requires_review)

4. Définissez l’environnement à interne si et seulement si la pull request vient du même dépôt. Autrement, définissez l’environnement à externe, ce qui nécessitera une approbation d’un réviseur pour continuer. ⚠️ NE SUPPRIMEZ PAS CETTE LIGNE ! (ex : environment: ${{ (github.event.pull_request.head.repo.full_name == github.repository && 'interne') || 'externe' }})

5. Créez un second job GitHub Actions pour exécuter vos benchmarks. (ex : benchmark_fork_pr_branch)

6. Faites en sorte que le job benchmark_fork_pr_branch nécessite le job fork_pr_requires_review pour s’exécuter. ⚠️ NE SUPPRIMEZ PAS CETTE LIGNE ! Voir la [documentation needs de GitHub Actions][github actions needs] pour un aperçu complet. (ex : needs: fork_pr_requires_review)

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

8. Vérifiez le code source de la PR du fork. Puisque pull_request_target s’exécute dans le contexte de la branche cible de la pull request, vous devez toujours checkout la branche de la pull request. (ex : uses: actions/checkout@v4)

   • Spécifiez le dépôt de la PR du fork (ex : repository: ${{ github.event.pull_request.head.repo.full_name }})
   • Spécifiez le hash de la PR du fork (ex : ref: ${{ github.event.pull_request.head.sha }})
   • Ne persistez pas votre identifiant git (ex : persist-credentials: false)

9. Installez le CLI Bencher en utilisant [l’Action GitHub][bencher cli github action]. (ex : uses: bencherdev/bencher@main)

10. Utilisez la sous-commande CLI bencher run pour exécuter les benchmarks de votre branche de pull request de fork. Voir [la sous-commande CLI bencher run][bencher run] pour un aperçu complet. (ex : bencher run)

11. Définissez l’option --project sur le slug du Projet. Voir [la doc --project][project option] pour plus de détails. (ex : —project save-walter-white-1234abcd`)

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

13. Définissez l’option --branch sur le numéro de PR de fork formaté en utilisant [l’évènement pull_request de GitHub Actions][github action pull_request]. Voir [la sélection de branche][branch selection branch] pour un aperçu complet. (ex : --branch '${{ github.event.number }}/merge')

14. Définissez l’option --branch-start-point sur le point de départ de la branche de base de la PR de fork en utilisant [le contexte github de GitHub Actions][github actions context]. Voir [la sélection de point de départ de branche][branch selection start point] pour un aperçu complet. (ex : --branch-start-point '${{ github.base_ref }}')

15. Définissez l’option --branch-start-point-hash sur le hash du point de départ de la branche de base de la PR de fork en utilisant [l’évènement pull_request de GitHub Actions][github action pull_request]. Voir [la sélection du hash du point de départ de branche][branch selection start point hash] pour un aperçu complet. (ex : --branch-start-point-hash '${{ github.event.pull_request.base.sha }}')

16. 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 doc --testbed][testbed option] pour plus de détails. (ex : --testbed ubuntu-latest)

17. Définissez l’option --adapter sur l’adaptateur souhaité pour le harnais de benchmark. Voir [les adaptateurs de harnais de benchmark][adapters] pour un aperçu complet. (ex : --adapter json)

18. Définissez l’indicateur --err pour faire échouer la commande si une alerte est générée. Voir [Seuils & Alertes][alerts] pour un aperçu complet. (ex : --err)

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

20. Spécifiez les arguments de la commande de benchmark. Voir [la commande de benchmark][command argument] pour un aperçu complet. (ex : bencher mock)

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

Continuez : Vue d’ensemble du Benchmarking ➡