Como usar o Bencher no GitHub Actions


Dependendo do seu caso de uso, você pode configurar Benchmarking Contínuo no GitHub Actions para o seu:

Certifique-se de criar um token de API e configurá-lo como um segredo de Repositório chamado BENCHER_API_TOKEN antes de continuar! Navegue até Seu Repositório -> Configurações -> Segredos e variáveis -> Ações -> Novo segredo de repositório. Nomeie o segredo como BENCHER_API_TOKEN e defina o valor do segredo para o seu token de API.

No GitHub Actions, segredos não são passados para o runner quando um workflow é acionado a partir de um repositório bifurcado. Portanto, você precisará usar um 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, então o segredo BENCHER_API_TOKEN não estará disponível. ${{ secrets.BENCHER_API_TOKEN }} será uma string vazia.

Ramificação Base

Um alicerce do Benchmarking Estatístico Contínuo é ter uma linha de base histórica para sua ramificação base. Essa linha de base histórica pode então ser usada para detectar regressões de desempenho nos Pull Requests.

.github/workflows/base_benchmarks.yml
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. Crie um arquivo workflow do GitHub Actions. (ex: .github/workflows/base_benchmarks.yml)
  2. Execute em eventos de push para a ramificação main. Veja a documentação de on do GitHub Actions e a documentação de push do GitHub Actions para uma visão geral completa. (ex: on: push: branches: main)
  3. Crie um job do GitHub Actions. (ex: jobs: benchmark_base_branch)
  4. Defina o tipo de máquina em que o job será executado. Veja a documentação de runs-on do GitHub Actions para uma visão geral completa. (ex: runs-on: ubuntu-latest)
  5. Faça o checkout do código-fonte da sua ramificação base. (ex: uses: actions/checkout@v4)
  6. Instale o Bencher CLI usando a Ação do GitHub. (ex: uses: bencherdev/bencher@main)
  7. Use o subcomando bencher run do CLI para executar os benchmarks da sua ramificação main. Veja o subcomando bencher run do CLI para uma visão geral completa. (ex: bencher run)
  8. Configure a opção --project para o slug do Projeto. Veja os documentos de --project para mais detalhes. (ex: --project save-walter-white-1234abcd)
  9. Configure a opção --token para o segredo Repositorio BENCHER_API_TOKEN. Veja os documentos de --token para mais detalhes. (ex: --token '${{ secrets.BENCHER_API_TOKEN }}')
  10. Configure a opção --branch para o nome da Ramificação base. Veja os documentos de --branch para uma visão geral completa. (ex: --branch main)
  11. Configure a opção --testbed para o nome do Testbed. Isso deve provavelmente coincidir com a máquina selecionada em runs-on. Veja os documentos de --tested para mais detalhes. (ex: --testbed ubuntu-latest)
  12. Configure o Limite para a Ramificação main, Testbed ubuntu-latest, e Medida latency:
    1. Configure a opção --threshold-measure para a medida latency embutida que é gerada por bencher mock. Veja os documentos de --threshold-measure para mais detalhes. (ex: --threshold-measure latency)
    2. Configure a opção --threshold-test para um teste-t de Student (t_test). Veja os documentos de --threshold-test para uma visão geral completa. (ex: --threshold-test t_test)
    3. Configure a opção --threshold-max-sample-size para o tamanho máximo da amostra de 64. Veja os documentos de --threshold-max-sample-size para mais detalhes. (ex: --threshold-max-sample-size 64)
    4. Configure a opção --threshold-upper-boundary para o Limite Superior de 0.99. Veja os documentos de --threshold-upper-boundary para mais detalhes. (ex: --threshold-upper-boundary 0.99)
    5. Defina a flag --thresholds-reset para que somente o Limite especificado esteja ativo. Veja os documentos de --thresholds-reset para uma visão geral completa. (ex: --thresholds-reset)
  13. Defina a flag --err para falhar o comando se um Alerta for gerado. Veja os documentos de --err para uma visão geral completa. (ex: --err)
  14. Configure a opção --adapter para o Bencher Metric Format JSON (json) que é gerado por bencher mock. Veja adapters do harness de benchmark para uma visão geral completa. (ex: --adapter json)
  15. Configure a opção --github-actions para o token de autenticação da API do GitHub para publicar resultados como um comentário de Checks do GitHub usando a variável de ambiente GITHUB_TOKEN do GitHub Actions. Veja os documentos de --github-actions para mais detalhes. (ex: --github-actions '${{ secrets.GITHUB_TOKEN }}')
  16. Especifique os argumentos do comando de benchmark. Veja comando de benchmark para uma visão geral completa. (ex: bencher mock)

Pull Requests

Para identificar regressões de desempenho em Pull Requests, você precisará executar seus benchmarks nos PRs. Se você espera ter PRs apenas de branches dentro do mesmo repositório, então pode simplesmente criar outro fluxo de trabalho para rodar eventos on pull_request do mesmo repositório.

⚠️ Esta solução só funciona se todos os PRs forem do mesmo repositório! Veja Pull Requests a partir de Forks abaixo.

.github/workflows/pr_benchmarks.yml
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. Crie um arquivo workflow do GitHub Actions. (ex: .github/workflows/pr_benchmarks.yml)

  2. Execute em eventos 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 o branch base de um pull request foi alterado.
    • synchronize - Um branch de cabeça de pull request foi atualizado. Por exemplo, o branch de cabeça foi atualizado a partir do branch base ou novos commits foram enviados ao branch de cabeça.

    Veja a documentação on do GitHub Actions e a documentação pull_request do GitHub Actions para uma visão geral completa. (ex: on: pull_request: types: [opened, reopened, edited, synchronize])

  3. Crie um job do GitHub Actions. (ex: jobs: benchmark_pr_branch)

  4. Execute em eventos pull_request se e somente se o pull request for do mesmo repositório. ⚠️ NÃO REMOVA ESTA LINHA! Para lidar com Fork PRs veja Pull Requests a partir de Forks abaixo. (ex: if: github.event_name == 'pull_request' && github.event.pull_request.head.repo.full_name == github.repository)

  5. Defina as permissões para o GITHUB_TOKEN como write para pull-requests. Dependendo das suas configurações no GitHub, isso pode não ser necessário. Mas para todas as organizações e repositórios pessoais criados após 02 de fevereiro de 2023, esse é o comportamento padrão. Veja a documentação do GitHub para uma visão geral completa. (ex: permissions: pull-requests: write)

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

  7. Faça o checkout do código fonte do branch do PR. (ex: uses: actions/checkout@v4)

  8. Instale o Bencher CLI usando a GitHub Action. (ex: uses: bencherdev/bencher@main)

  9. Use o subcomando CLI bencher run para rodar seus benchmarks do branch de pull request. Veja o subcomando CLI bencher run para uma visão geral completa. (ex: bencher run)

  10. Defina a opção --project para o slug do Projeto. Veja a documentação --project para mais detalhes. (ex: --project save-walter-white-1234abcd)

  11. Defina a opção --token para o segredo de Repositório BENCHER_API_TOKEN. Veja a documentação --token para mais detalhes. (ex: --token '${{ secrets.BENCHER_API_TOKEN }}')

  12. Defina a opção --branch para o nome do branch do PR usando o contexto github do GitHub Actions. Veja a documentação --branch para uma visão geral completa. (ex: --branch '${{ github.head_ref }}')

  13. Defina o Ponto Inicial para o Branch do PR:

    1. Defina a opção --start-point para o ponto inicial do Branch do PR usando o contexto github do GitHub Actions. Veja a documentação --start-point para uma visão geral completa. (ex: --start-point '${{ github.base_ref }}')
    2. Defina a opção --start-point-hash para o git hash do ponto inicial do Branch do PR usando o evento pull_request do GitHub Actions. Veja a documentação --start-point-hash para uma visão geral completa. (ex: --start-point-hash '${{ github.event.pull_request.base.sha }}')
    3. Defina a flag --start-point-clone-thresholds para clonar os Limiares do ponto inicial. Veja a documentação --start-point-clone-thresholds para uma visão geral completa. (ex: --start-point-clone-thresholds)
    4. Defina a flag --start-point-reset para sempre redefinir o Branch do PR para o ponto inicial. Isso evitará o desvio de dados de benchmark. Veja a documentação --start-point-reset para uma visão geral completa. (ex: --start-point-reset)
  14. Defina a opção --testbed para o nome do Testbed. Este provavelmente deve coincidir com a máquina selecionada em runs-on. Veja a documentação --tested para mais detalhes. (ex: --testbed ubuntu-latest)

  15. Defina a flag --err para falhar o comando se um Alerta for gerado. Veja a documentação --err para uma visão geral completa. (ex: --err)

  16. Defina a opção --adapter para Formato de Métrica Bencher JSON (json) que é gerado por bencher mock. Veja adapters de benchmarks para uma visão geral completa. (ex: --adapter json)

  17. 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 ambiente GITHUB_TOKEN do GitHub Actions. Veja a documentação --github-actions para mais detalhes. (ex: --github-actions '${{ secrets.GITHUB_TOKEN }}')

  18. Especifique os argumentos do comando do benchmark. Veja comando do benchmark para uma visão geral completa. (ex: bencher mock)

Para limpar a branch do PR após seu fechamento, você pode criar um fluxo de trabalho separado para executar on eventos de pull_request com o tipo closed. Este fluxo de trabalho arquivará a branch do PR usando o comando bencher archive.

.github/workflows/pr_benchmarks_closed.yml
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. Crie um arquivo de workflow do GitHub Actions. (ex: .github/workflows/pr_benchmarks_closed.yml)

  2. Execute em eventos de pull_request:

    • closed - Um pull request foi fechado.

    Veja a documentação do GitHub Actions on e a documentação do pull_request do GitHub Actions para uma visão geral completa. (ex: on: pull_request: types: [closed])

  3. Crie um job do GitHub Actions. (ex: jobs: archive_pr_branch)

  4. Execute em eventos de pull_request se e somente se o pull request for do mesmo repositório. ⚠️ NÃO REMOVA ESTA LINHA! Para lidar com 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)

  5. Defina as permissões para o GITHUB_TOKEN como write para pull-requests. Dependendo das suas configurações do GitHub, isso 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)

  6. Defina o tipo de máquina no qual o job será executado. Veja a documentação do runs-on do GitHub Actions para uma visão geral completa. (ex: runs-on: ubuntu-latest)

  7. Faça checkout do código fonte da branch do PR. (ex: uses: actions/checkout@v4)

  8. Instale o Bencher CLI usando a Ação do GitHub. (ex: uses: bencherdev/bencher@main)

  9. Use o subcomando bencher archive da CLI para arquivar a branch do PR. (ex: bencher archive)

  10. Defina a opção --project para o slug do Projeto. Veja os documentos do --project para mais detalhes. (ex: --project save-walter-white-1234abcd)

  11. Defina a opção --token para o segredo Repositório BENCHER_API_TOKEN. Veja os documentos do --token para mais detalhes. (ex: --token '${{ secrets.BENCHER_API_TOKEN }}')

  12. Defina a opção --branch para o nome da branch do PR usando o contexto github do GitHub Actions. (ex: --branch '${{ github.head_ref }}')


Pull Requests de Forks

Se você planeja aceitar pull requests de forks, como é frequentemente o caso em projetos de código aberto público, então você precisará lidar com as coisas de maneira um pouco diferente. Por razões de segurança, segredos como seu BENCHER_API_TOKEN e o GITHUB_TOKEN não estão disponíveis no GitHub Actions para PRs de fork. Ou seja, se um colaborador externo abrir um PR a partir de um fork, o exemplo acima não funcionará. Veja este artigo do GitHub Security Lab e esta postagem no blog sobre como prevenir requests maliciosos para uma visão completa.

Esta é a maneira segura e sugerida de adicionar Benchmarking Contínuo a pull requests de forks. Requer dois fluxos de trabalho separados. O primeiro fluxo de trabalho executa e armazena em cache os resultados do benchmark no contexto pull_request. Nenhum segredo, como seu BENCHER_API_TOKEN e o GITHUB_TOKEN, está disponível lá. Então, um segundo fluxo de trabalho baixa os resultados do benchmark em cache no contexto workflow_run e os envia para o Bencher. Isso funciona porque workflow_run é executado no contexto do branch padrão do repositório, onde segredos como seu BENCHER_API_TOKEN e o GITHUB_TOKEN estão disponíveis. O número do pull request, o branch head e o branch base usados no fluxo de trabalho inicial pull_request também devem ser explicitamente passados para o fluxo de trabalho workflow_run, pois não estão disponíveis lá. Esses fluxos de trabalho só serão executados se existirem no branch padrão. Veja usando dados do workflow que disparou a execução para uma visão completa.

.github/workflows/fork_pr_benchmarks_run.yml
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. Crie um primeiro arquivo de workflow do GitHub Actions. (ex: .github/workflows/fork_pr_benchmarks_run.yml)

  2. Nomeie esse workflow para que ele possa ser referenciado pelo segundo workflow. (ex: name: Run Benchmarks)

  3. 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 o branch base de um pull request foi alterado.
    • synchronize - O branch head de um pull request foi atualizado. Por exemplo, o branch head foi atualizado do branch base ou novos commits foram enviados para o branch head.

    Consulte a documentação de on do GitHub Actions e a documentação de pull_request do GitHub Actions para uma visão completa. (ex: on: pull_request: types: [opened, reopened, edited, synchronize])

  4. Crie um job do GitHub Actions. (ex: jobs: benchmark_fork_pr_branch)

  5. Defina o tipo de máquina em que o job será executado. Consulte a documentação de runs-on do GitHub Actions para uma visão completa. (ex: runs-on: ubuntu-latest)

  6. Faça o checkout do código-fonte do fork PR. (ex: uses: actions/checkout@v4)

  7. Execute seus benchmarks e salve os resultados em um arquivo. (ex: /bin/echo '{ ... }' > benchmark_results.json)

  8. Envie o arquivo de resultados de benchmark como um artefato. (ex: uses: actions/upload-artifact@v4)

  9. Envie o objeto de evento pull_request como um artefato. (ex: uses: actions/upload-artifact@v4)

.github/workflows/fork_pr_benchmarks_track.yml
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. Crie um primeiro arquivo de workflow do GitHub Actions. (ex: .github/workflows/fork_pr_benchmarks_track.yml)
  2. Nomeie este workflow como segundo workflow. (ex: name: Track Benchmarks with Bencher)
  3. Encadeie os dois workflows com o evento workflow_run. (ex: on: workflow_run: ...)
  4. Crie um job do GitHub Actions. (ex: jobs: track_fork_pr_branch)
  5. Execute este job apenas se a conclusão do workflow anterior for um sucesso usando o evento workflow_run do GitHub Actions. (ex: if: github.event.workflow_run.conclusion == 'success')
  6. Defina o tipo de máquina em que o job será executado. Veja a documentação runs-on do GitHub Actions para uma visão geral completa. (ex: runs-on: ubuntu-latest)
  7. Defina os nomes dos arquivos de resultados do benchmark e do objeto do evento pull_request como variáveis de ambiente. (ex: env: ...)
  8. Baixe os resultados do benchmark em cache e o evento pull_request usando o GitHub Action action-download-artifact. (ex: uses: dawidd6/action-download-artifact@v6)
  9. Exporte os dados necessários do evento pull_request como variáveis de ambiente. (ex: core.exportVariable(...))
  10. Instale o CLI do Bencher usando o GitHub Action. (ex: uses: bencherdev/bencher@main)
  11. Use o subcomando CLI bencher run para rastrear os benchmarks do branch do fork pull. Veja o subcomando CLI bencher run para uma visão geral completa. (ex: bencher run)
  12. Defina a opção --project para o slug do Projeto. Veja a documentação --project para mais detalhes. (ex: --project save-walter-white-1234abcd)
  13. Defina a opção --token para o segredo do Repositório BENCHER_API_TOKEN. Veja a documentação --token para mais detalhes. (ex: --token '${{ secrets.BENCHER_API_TOKEN }}')
  14. Defina a opção --branch para o nome do branch do fork PR usando [o contexto github do GitHub Actions][github actions context]. Veja a documentação --branch para uma visão geral completa. (ex: --branch '${{ env.PR_HEAD }}')
  15. Defina o Ponto de Início para o Branch do fork PR:
    1. Defina a opção --start-point para o ponto de início do Branch do fork PR usando [o contexto github do GitHub Actions][github actions context]. Veja a documentação --start-point para uma visão geral completa. (ex: --start-point '${{ env.PR_BASE }}')
    2. Defina a opção --start-point-hash para o hash git do ponto de início do Branch do fork PR usando o evento pull_request do GitHub Actions. Veja a documentação --start-point-hash para uma visão geral completa. (ex: --start-point-hash '${{ env.PR_BASE_SHA }}')
    3. Defina o flag --start-point-clone-thresholds para clonar os Limiares do ponto de início. Veja a documentação --start-point-clone-thresholds para uma visão geral completa. (ex: --start-point-clone-thresholds)
    4. Defina o flag --start-point-reset para sempre redefinir o Branch do fork PR para o ponto de início. Isso evitará a deriva dos dados de benchmark. Veja a documentação --start-point-reset para uma visão geral completa. (ex: --start-point-reset)
  16. Defina a opção --testbed para o nome do Testbed. Isso deve provavelmente corresponder à máquina selecionada em runs-on. Veja a documentação --testbed para mais detalhes. (ex: --testbed ubuntu-latest)
  17. Defina o flag --err para falhar o comando se um Alerta for gerado. Veja a documentação --err para uma visão geral completa. (ex: --err)
  18. Defina a opção --adapter para o Formato Métrico JSON do Bencher (json) que é gerado por bencher mock. Veja adaptadores de benchmark harness para uma visão geral completa. (ex: --adapter json)
  19. 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 ambiente GITHUB_TOKEN do GitHub Actions. Veja a documentação --github-actions para mais detalhes. (ex: --github-actions '${{ secrets.GITHUB_TOKEN }}')
  20. 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 }}')
  21. Defina a opção --file para o caminho do arquivo de resultados do benchmark. Veja comando de benchmark para uma visão geral completa. (ex: --file "$BENCHMARK_RESULTS")

Para limpar o branch do PR do fork após o PR ser fechado, você pode criar um workflow separado para rodar on eventos de pull_request com o tipo closed. Esse workflow arquivará o branch do PR do fork usando o comando bencher archive.

.github/workflows/fork_pr_benchmarks_closed.yml
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. Crie um arquivo de workflow do GitHub Actions. (ex: .github/workflows/fork_pr_benchmarks_closed.yml)

  2. Execute em eventos de pull_request:

    • closed - Um pull request foi fechado.

    Veja a documentação do on do GitHub Actions e a documentação do pull_request do GitHub Actions para uma visão completa. (ex: on: pull_request: types: [closed])

  3. Crie um job do GitHub Actions. (ex: jobs: archive_pr_branch)

  4. Defina as permissões para o GITHUB_TOKEN como write para pull-requests. Dependendo das suas configurações do GitHub, isso 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 completa. (ex: permissions: pull-requests: write)

  5. Defina o tipo de máquina em que o job será executado. Veja a documentação do runs-on do GitHub Actions para uma visão completa. (ex: runs-on: ubuntu-latest)

  6. Faça checkout do código-fonte do branch do PR. (ex: uses: actions/checkout@v4)

  7. Instale o Bencher CLI usando a GitHub Action. (ex: uses: bencherdev/bencher@main)

  8. Use o subcomando da CLI bencher archive para arquivar o branch do PR. (ex: bencher archive)

  9. Defina a opção --project para o slug do Projeto. Veja a documentação de --project para mais detalhes. (ex: --project save-walter-white-1234abcd)

  10. Defina a opção --token para o segredo Repository BENCHER_API_TOKEN. Veja a documentação de --token para mais detalhes. (ex: --token '${{ secrets.BENCHER_API_TOKEN }}')

  11. Defina a opção --branch para o nome do branch do PR usando o contexto github do GitHub Actions. (ex: --branch '${{ github.head_ref }}')



🐰 Parabéns! Você aprendeu como usar o Bencher no GitHub Actions! 🎉


Continue a Aprender: Visão Geral do Benchmarking ➡

🤖 Este documento foi gerado automaticamente pelo OpenAI GPT-4. Pode não ser preciso e pode conter erros. Se você encontrar algum erro, abra um problema no GitHub.


Published: Fri, October 27, 2023 at 8:40:00 AM UTC | Last Updated: Sat, October 12, 2024 at 12:40:00 PM UTC