Como usar o Bencher no GitHub Actions
Dependendo do seu caso de uso, você pode configurar o Benchmarking Contínuo no GitHub Actions para o seu:
- Branch Base
- Pull Requests
- Pull Requests de Forks
- ⛑️ Mais seguro: Benchmark de PR de Fork e Upload a partir do Branch Padrão
- ⚠️ Mais arriscado: Benchmark de PR de Fork a partir do Branch Alvo com Revisores Obrigatórios
Certifique-se de ter criado um token da API
e configurá-lo como um segredo do Repositório chamado BENCHER_API_TOKEN
antes de continuar!
Navegue até Seu Repositório -> Configurações -> Segredos e variáveis -> Ações -> Novo segredo do repositório
.
Nomeie o segredo como BENCHER_API_TOKEN
e defina o valor do segredo para o seu token da API.
Em GitHub Actions,
segredos não são passados para o runner quando um workflow é disparado a partir de um repositório bifurcado.
Portanto, você precisará usar uma branch do mesmo repositório
ao adicionar qualquer um dos workflows abaixo ao seu repositório com um pull request.
Se você tentar adicionar o Bencher com um pull request de um fork,
o segredo BENCHER_API_TOKEN
não estará disponível.
${{ secrets.BENCHER_API_TOKEN }}
será uma string vazia.
Ramo Base
Um pilar do Benchmarking Contínuo Estatístico é ter uma linha de base histórica para o seu ramo base. Essa linha de base histórica pode então ser utilizada para detectar regressões de desempenho em 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
- Crie um arquivo
workflow
do GitHub Actions. (ex:.github/workflows/base_benchmarks.yml
) - Execute em eventos de
push
para o ramomain
. Veja a documentaçãoon
do GitHub Actions e a documentaçãopush
do GitHub Actions para uma visão geral completa. (ex:on: push: branches: main
) - Crie um
job
do GitHub Actions. (ex:jobs: benchmark_base_branch
) - Defina o tipo de máquina em que o trabalho será executado.
Veja a documentação
runs-on
do GitHub Actions para uma visão geral completa. (ex:runs-on: ubuntu-latest
) - Faça checkout do código-fonte do seu ramo base.
(ex:
uses: actions/checkout@v4
) - Instale o CLI Bencher usando a GitHub Action.
(ex:
uses: bencherdev/bencher@main
) - Use o subcomando CLI
bencher run
para executar os benchmarks do seu ramomain
. Veja o subcomando CLIbencher run
para uma visão geral completa. (ex:bencher run
) - Defina a opção
--project
para o slug do Projeto. Veja os docs--project
para mais detalhes. (ex:--project save-walter-white-1234abcd
) - Defina a opção
--token
para o segredo RepositórioBENCHER_API_TOKEN
. Veja os docs--token
para mais detalhes. (ex:--token '${{ secrets.BENCHER_API_TOKEN }}'
) - Defina a opção
--branch
para o nome do Ramo. Veja seleção de ramo para uma visão geral completa. (ex:--branch main
) - Defina a opção
--testbed
para o nome da Base de teste. Isso provavelmente deve corresponder à máquina selecionada emruns-on
. Veja os docs--tested
para mais detalhes. (ex:--testbed ubuntu-latest
) - Defina a opção
--adapter
para o adaptador de conjunto de benchmarks desejado. Veja adaptadores de conjunto de benchmarks para uma visão geral completa. (ex:--adapter json
) - Defina a flag
--err
para falhar o comando se um Alerta for gerado. Veja Limiares & Alertas para uma visão geral completa. (ex:--err
) - Especifique os argumentos do comando de benchmark.
Veja comando de benchmark para uma visão geral completa.
(ex:
bencher mock
)
Pull Requests
Para capturar regressões de desempenho em Pull Requests, você precisará executar seus benchmarks em PRs.
Se você espera ter PRs apenas de branches dentro do mesmo repositório,
então você pode simplesmente criar outro workflow para rodar on
eventos de pull_request
do mesmo repositório.
⚠️ Esta solução só funciona se todos os PRs vierem do mesmo repositório! Veja Pull Requests de Forks abaixo.
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 }}' \ --branch-reset \ --testbed ubuntu-latest \ --adapter json \ --err \ --github-actions '${{ secrets.GITHUB_TOKEN }}' \ bencher mock
-
Crie um arquivo de
workflow
do GitHub Actions. (ex:.github/workflows/pr_benchmarks.yml
) -
Execute em eventos de
pull_request
:opened
- Um pull request foi criado.reopened
- Um pull request previamente fechado foi reaberto.edited
- O título ou corpo de um pull request foi editado, ou a branch base de um pull request foi alterada.synchronize
- A branch head de um pull request foi atualizada. Por exemplo, a branch head foi atualizada a partir da branch base ou novos commits foram enviados à branch head.
Veja a documentação
on
do GitHub Actions e a documentaçãopull_request
do GitHub Actions para uma visão geral completa. (ex:on: pull_request: types: [opened, reopened, edited, synchronize]
) -
Crie um
job
do GitHub Actions. (ex:jobs: benchmark_pr_branch
) -
Execute em eventos de
pull_request
se e somente se o pull request for do mesmo repositório. ⚠️ NÃO REMOVA ESTA LINHA! Para tratar PRs de Forks veja Pull Requests de Forks abaixo. (ex:if: github.event_name == 'pull_request' && github.event.pull_request.head.repo.full_name == github.repository
) -
Configure as permissões para o
GITHUB_TOKEN
parawrite
empull-requests
. Dependendo das suas configurações do GitHub, isto pode não ser necessário. Mas para todas as organizações e repositórios pessoais criados após 02 de fevereiro de 2023, este é o comportamento padrão. Veja a documentação do GitHub para uma visão geral completa. (ex:permissions: pull-requests: write
) -
Defina o tipo de máquina onde o job será executado. Veja a documentação
runs-on
do GitHub Actions para uma visão geral completa. (ex:runs-on: ubuntu-latest
) -
Faça checkout do código-fonte da branch do PR. (ex:
uses: actions/checkout@v4
) -
Instale o Bencher CLI usando a Ação do GitHub. (ex:
uses: bencherdev/bencher@main
) -
Use o subcomando
bencher run
CLI para rodar os benchmarks da branch do pull request. Veja o subcomandobencher run
CLI para uma visão geral completa. (ex:bencher run
) -
Defina a opção
--project
para o slug do Projeto. Veja a documentação da opção--project
para mais detalhes. (ex:--project save-walter-white-1234abcd
) -
Defina a opção
--token
para o segredo do RepositórioBENCHER_API_TOKEN
. Veja a documentação da opção--token
para mais detalhes. (ex:--token '${{ secrets.BENCHER_API_TOKEN }}'
) -
Defina a opção
--branch
para o nome da branch do PR utilizando o contextogithub
do GitHub Actions. Veja a seleção de branch para uma visão geral completa. (ex:--branch '${{ github.head_ref }}'
) -
Defina a opção
--branch-start-point
para o ponto de início da Branch base do PR utilizando o contextogithub
do GitHub Actions. Veja a seleção de branch para uma visão geral completa. (ex:--branch-start-point '${{ github.base_ref }}'
) -
Defina a opção
--branch-start-point-hash
para o hash do ponto de início da Branch base do PR utilizando o eventopull_request
do GitHub Actions. Veja a seleção de branch para uma visão geral completa. (ex:--branch-start-point-hash '${{ github.event.pull_request.base.sha }}'
) -
Defina a flag
--branch-reset
para sempre resetar a Branch para o ponto inicial. Isso evitará a deriva de dados de benchmark. Veja a seleção de branch para uma visão geral completa. (ex:--branch-reset
) -
Defina a opção
--testbed
para o nome do Testbed. Isso deve provavelmente combinar com a máquina selecionada emruns-on
. Veja a documentação da opção--tested
para mais detalhes. (ex:--testbed ubuntu-latest
) -
Defina a opção
--adapter
para o adaptador de harness de benchmark desejado. Veja adapters de harness de benchmark para uma visão geral completa. (ex:--adapter json
) -
Defina a flag
--err
para falhar o comando se um Alerta for gerado. Veja Threshold & Alerts para uma visão geral completa. (ex:--err
) -
Defina a opção
--github-actions
para o token de autenticação da API do GitHub para postar resultados como um comentário no Pull Request utilizando a variável de ambienteGITHUB_TOKEN
do GitHub Actions. Veja a documentação da opção--github-actions
para mais detalhes. (ex:--github-actions '${{ secrets.GITHUB_TOKEN }}'
) -
Especifique os argumentos do comando de benchmark. Veja comando de benchmark para uma visão geral completa. (ex:
bencher mock
)
Pull Requests a Partir de Forks
Se você planeja aceitar pull requests de forks, como é frequentemente o caso em projetos open source públicos,
então você precisará lidar com as coisas de maneira um pouco diferente.
Por razões de segurança, secrets como seu BENCHER_API_TOKEN
e o GITHUB_TOKEN
não estão disponíveis no GitHub Actions para PRs de forks.
Isso quer dizer que, se um contribuidor externo abrir um PR a partir de um fork, o exemplo acima não funcionará.
Existem duas opções para PRs de forks:
- ⛑️ Mais seguro: Benchmark Fork PR e Upload a Partir da Branch Padrão
- ⚠️ Mais arriscado: Benchmark Fork PR da Branch de Destino com Revisores Obrigatórios
Veja este artigo do GitHub Security Lab e este post do blog sobre a prevenção de solicitações de pwn para uma visão geral completa.
Benchmark Fork PR e Upload da Branch Padrão
Este é o jeito seguro e sugerido de adicionar Benchmarking Contínuo a pull requests de forks.
Ele requer dois fluxos de trabalho distintos.
O primeiro fluxo de trabalho executa e guarda em cache os resultados do benchmark no contexto de pull_request
.
Nenhum segredo, como o seu BENCHER_API_TOKEN
e o GITHUB_TOKEN
, está disponível ali.
Então, um segundo fluxo de trabalho baixa os resultados armazenados em cache no contexto de workflow_run
e os envia para o Bencher.
Isso funciona porque o workflow_run
é executado no contexto da branch padrão do repositório,
onde segredos como o seu BENCHER_API_TOKEN
e o GITHUB_TOKEN
estão disponíveis.
O número do pull request, a branch head e a branch base utilizados no fluxo de trabalho inicial de pull_request
também devem ser passados explicitamente para o fluxo de trabalho workflow_run
, já que não estão disponíveis ali.
Esses fluxos de trabalho só serão executados se existirem na branch padrão.
Veja usando dados do fluxo de trabalho de gatilho para uma visão completa.
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 }}
-
Crie um primeiro arquivo de
workflow
do GitHub Actions. (ex:.github/workflows/run_fork_pr_benchmarks.yml
) -
Dê um nome a este fluxo de trabalho para que ele possa ser referenciado pelo segundo fluxo de trabalho. (ex:
name: Run and Cache Benchmarks
) -
Execute em eventos de
pull_request
:opened
- Um pull request foi criado.reopened
- Um pull request anteriormente fechado foi reaberto.edited
- O título ou corpo de um pull request foi editado, ou a branch base de um pull request foi alterada.synchronize
- A branch head de um pull request foi atualizada. Por exemplo, a branch head foi atualizada da branch base ou novos commits foram empurrados para a branch head.
Veja a documentação do GitHub Actions
on
e a documentação do GitHub Actionspull_request
para uma visão completa. (ex:on: pull_request: types: [opened, reopened, edited, synchronize]
) -
Crie um
job
no GitHub Actions. (ex:jobs: benchmark_fork_pr_branch
) -
Defina o tipo de máquina em que o job será executado. Veja a documentação do GitHub Actions
runs-on
para uma visão completa. (ex:runs-on: ubuntu-latest
) -
Faça checkout do código fonte da branch PR fork. (ex:
uses: actions/checkout@v4
) -
Execute seus benchmarks e salve os resultados em um arquivo. (ex:
/bin/echo '{ ... }' > benchmark_results.json
) -
Envie o arquivo de resultados do benchmark como um artefato. (ex:
uses: actions/upload-artifact@v4
) -
Envie o evento
pull_request
como um artefato. (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 }}' \ --branch-reset \ --testbed ubuntu-latest \ --adapter json \ --err \ --github-actions '${{ secrets.GITHUB_TOKEN }}' \ --ci-number '${{ env.PR_NUMBER }}' \ --file "$BENCHMARK_RESULTS"
- Crie um primeiro arquivo de
workflow
no GitHub Actions. (ex:.github/workflows/track_fork_pr_benchmarks.yml
) - Dê um nome a este segundo fluxo de trabalho.
(ex:
name: Track Benchmarks with Bencher
) - Encadeie os dois fluxos de trabalho com
o evento
workflow_run
. (ex:on: workflow_run: ...
) - Crie um
job
no GitHub Actions. (ex:jobs: track_fork_pr_branch
) - Execute este job apenas se a conclusão do fluxo de trabalho anterior foi bem-sucedida utilizando
o evento
workflow_run
do GitHub Actions. (ex:if: github.event.workflow_run.conclusion == 'success'
) - Defina o tipo de máquina em que o job será executado.
Veja a documentação do GitHub Actions
runs-on
para uma visão completa. (ex:runs-on: ubuntu-latest
) - Defina os nomes dos arquivos de resultados do benchmark e do evento
pull_request
como variáveis de ambiente. (ex:env: ...
) - Baixe os resultados do benchmark armazenados em cache e o evento
pull_request
. (ex:uses: actions/github-script@v6
) - Extraia os resultados do benchmark armazenados em cache e o evento
pull_request
. (ex:unzip ...
) - Exporte os dados necessários do evento
pull_request
como variáveis de ambiente. (ex:core.exportVariable(...)
) - Instale o Bencher CLI utilizando a Ação do GitHub.
(ex:
uses: bencherdev/bencher@main
) - Use o subcomando
bencher run
CLI para rastrear os benchmarks da branch pull fork. Veja o subcomandobencher run
CLI para uma visão completa. (ex:bencher run
) - Defina a opção
--project
para o Slug do Projeto. Veja a documentação--project
para mais detalhes. (ex:--project save-walter-white-1234abcd
) - Defina a opção
--token
para o segredo do RepositórioBENCHER_API_TOKEN
. Veja a documentação--token
para mais detalhes. (ex:--token '${{ secrets.BENCHER_API_TOKEN }}'
) - Defina a opção
--branch
para o número formatado do PR fork usando o eventopull_request
do GitHub Actions. Veja seleção de branch para uma visão completa. (ex:--branch '${{ env.PR_HEAD }}'
) - Defina a opção
--branch-start-point
para o ponto de início da branch base do PR fork usando o eventopull_request
do GitHub Actions. Veja seleção de branch para uma visão completa. (ex:--branch-start-point '${{ env.PR_BASE }}'
) - Defina a opção
--branch-start-point-hash
para o hash do ponto de início da branch base do PR fork usando o eventopull_request
do GitHub Actions. Veja seleção de branch para uma visão completa. (ex:--branch-start-point-hash '${{ env.PR_BASE_SHA }}'
) - Defina a flag
--branch-reset
para sempre resetar a branch para o ponto de início. Isso prevenirá o desvio de dados de benchmark. Veja seleção de branch para uma visão completa. (ex:--branch-reset
) - Defina a opção
--testbed
para o nome do Testbed. Isso provavelmente deve corresponder à máquina selecionada emruns-on
. Veja a documentação--testbed
para mais detalhes. (ex:--testbed ubuntu-latest
) - Defina a opção
--adapter
para o adaptador de harness de benchmark desejado. Veja adaptadores de harness de benchmark para uma visão completa. (ex:--adapter json
) - Defina a flag
--err
para falhar o comando se um Alerta for gerado. Veja Threshold & Alerts para uma visão completa. (ex:--err
) - Defina a opção
--github-actions
para o token de autenticação da API do GitHub para postar resultados como um comentário no Pull Request usando a variável de ambienteGITHUB_TOKEN
do GitHub Actions. Veja a documentação--github-actions
para mais detalhes. (ex:--github-actions '${{ secrets.GITHUB_TOKEN }}'
) - Defina a opção
--ci-number
para o número do pull request. Veja a documentação--ci-number
para mais detalhes. (ex:--ci-number '${{ env.PR_NUMBER }}'
) - Defina a opção
--file
para o caminho do arquivo de resultados do benchmark. Veja comando de benchmark para uma visão completa. (ex:--file "$BENCHMARK_RESULTS"
)
Benchmark Fork PR from Target Branch with Required Reviewers
Para garantir que o código de uma pull request de fork é seguro, esta GitHub Action verifica se o fork é de outro repositório. Se o fork for de outro repositório, então ele precisará ser revisado.
⚠️ É muito, muito importante revisar minuciosamente cada PR de fork antes de aprovar! Não fazer isso pode resultar em uma pwn request!
Se você preferir não ter essa responsabilidade, veja Benchmark Fork PR e Upload do Branch Padrão acima.
Para configurar este fluxo de trabalho, você precisa criar dois
Ambientes de GitHub Actions.
Navegue para Seu Repositório -> Configurações -> Ambientes -> Novo ambiente
.
Crie dois novos ambientes, internal
e external
.
O ambiente internal
não deve ter Regras de proteção de implementação
.
No entanto, o ambiente external
deve ter Revisores obrigatórios
definidos para aqueles que são confiáveis para revisar PRs de fork antes da avaliação de desempenho.
Veja esta postagem no blog para uma visão geral completa.
Esta configuração funciona porque pull_request_target
é executado no contexto do branch de destino do pull request,
onde segredos, como seu BENCHER_API_TOKEN
e o GITHUB_TOKEN
, estão disponíveis.
Portanto, este fluxo de trabalho só será executado se existir no branch de destino.
Evite definir quaisquer segredos como variáveis de ambiente, como GITHUB_TOKEN
e BENCHER_API_TOKEN
.
Em vez disso, passe explicitamente seus segredos para 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 }}' \ --branch-reset \ --testbed ubuntu-latest \ --adapter json \ --err \ --github-actions '${{ secrets.GITHUB_TOKEN }}' \ bencher mock
-
Crie um arquivo
workflow
de GitHub Actions. (ex:.github/workflows/pr_target_benchmarks.yml
) -
Execute eventos
pull_request
:opened
- Uma pull request foi criada.reopened
- Uma pull request anteriormente fechada foi reaberta.edited
- O título ou corpo de uma pull request foi editado, ou o branch base de uma pull request foi alterado.synchronize
- O branch de origem de uma pull request foi atualizado. Por exemplo, o branch de origem foi atualizado a partir do branch base ou novos commits foram enviados para o branch de origem.
Veja a documentação sobre
on
do GitHub Actions e a documentação sobrepull_request
do GitHub Actions para uma visão geral completa. (ex:on: pull_request: types: [opened, reopened, edited, synchronize]
) -
Crie um primeiro
job
de GitHub Actions para verificar se o fluxo de trabalho necessita de revisão. (ex:jobs: fork_pr_requires_review
) -
Defina o
environment
parainternal
se e somente se a pull request for do mesmo repositório. Caso contrário, defina oenvironment
paraexternal
, que exigirá uma aprovação de um revisor para continuar. ⚠️ NÃO REMOVA ESTA LINHA! (ex:environment: ${{ (github.event.pull_request.head.repo.full_name == github.repository && 'internal') || 'external' }}
) -
Crie um segundo
job
de GitHub Actions para executar suas benchmarks. (ex:benchmark_fork_pr_branch
) -
Faça o
job
benchmark_fork_pr_branch
depender dojob
fork_pr_requires_review
para ser executado. ⚠️ NÃO REMOVA ESTA LINHA! Veja a documentação sobreneeds
do GitHub Actions para uma visão geral completa. (ex:needs: fork_pr_requires_review
) -
Defina o tipo de máquina em que o job será executado. Veja a documentação sobre
runs-on
do GitHub Actions para uma visão geral completa. (ex:runs-on: ubuntu-latest
) -
Faça checkout do código fonte do PR de fork. Como
pull_request_target
é executado no contexto do branch de destino do pull request, você ainda precisa fazer checkout do branch do pull request. (ex:uses: actions/checkout@v4
)- Especifique o repositório do PR de fork (ex:
repository: ${{ github.event.pull_request.head.repo.full_name }}
) - Especifique o hash do PR de fork (ex:
ref: ${{ github.event.pull_request.head.sha }}
) - Não persista sua credencial
git
(ex:persist-credentials: false
)
- Especifique o repositório do PR de fork (ex:
-
Instale o Bencher CLI usando a GitHub Action. (ex:
uses: bencherdev/bencher@main
) -
Use o subcomando do CLI
bencher run
para executar seus benchmarks no branch do PR de fork. Veja o subcomandobencher run
CLI para uma visão geral completa. (ex:bencher run
) -
Defina a opção
--project
para o slug do Projeto. Veja a documentação da opção--project
para mais detalhes. (ex:--project save-walter-white-1234abcd
) -
Defina a opção
--token
para o segredo do RepositórioBENCHER_API_TOKEN
. Veja a documentação da opção--token
para mais detalhes. (ex:--token '${{ secrets.BENCHER_API_TOKEN }}'
) -
Defina a opção
--branch
para o número do PR de fork formatado usando o eventopull_request
do GitHub Actions. Veja a seleção de branch para uma visão geral completa. (ex:--branch '${{ github.event.number }}/merge'
) -
Defina a opção
--branch-start-point
para o ponto de início do branch base do PR de fork usando o contextogithub
do GitHub Actions. Veja a seleção de branch para uma visão geral completa. (ex:--branch-start-point '${{ github.base_ref }}'
) -
Defina a opção
--branch-start-point-hash
para o hash do ponto de início do branch base do PR de fork usando o eventopull_request
do GitHub Actions. Veja a seleção de branch para uma visão geral completa. (ex:--branch-start-point-hash '${{ github.event.pull_request.base.sha }}'
) -
Defina a flag
--branch-reset
para sempre redefinir o branch para o ponto de início. Isso evitará a deriva dos dados de benchmark. Veja a seleção de branch para uma visão geral completa. (ex:--branch-reset
) -
Defina a opção
--testbed
para o nome do Testbed. Isso deve provavelmente corresponder à máquina selecionada emruns-on
. Veja a documentação da opção--testbed
para mais detalhes. (ex:--testbed ubuntu-latest
) -
Defina a opção
--adapter
para o adaptador de harness de benchmark desejado. Veja os adaptadores de harness de benchmark para uma visão geral completa. (ex:--adapter json
) -
Defina a flag
--err
para falhar o comando se um Alerta for gerado. Veja Limites e Alertas para uma visão geral completa. (ex:--err
) -
Defina a opção
--github-actions
para o token de autenticação da API do GitHub para postar resultados como um comentário na Pull Request usando a variável de ambienteGITHUB_TOKEN
do GitHub Actions. Veja a documentação da opção--github-actions
para mais detalhes. (ex:--github-actions '${{ secrets.GITHUB_TOKEN }}'
) -
Especifique os argumentos do comando de benchmark. Veja comando de benchmark para uma visão geral completa. (ex:
bencher mock
)
🐰 Parabéns! Você aprendeu como usar o Bencher no GitHub Actions! 🎉