Cómo usar Bencher en GitHub Actions

Dependiendo de su caso de uso, puede configurar Evaluación continua en GitHub Actions para su:

• Rama Base
• Solicitudes de Pull
• Solicitudes de Pull desde Forks
  • ⛑️ Más seguro: Evaluar PR de Fork y Subir desde la Rama Predeterminada
  • ⚠️ Más arriesgado: Evaluar PR de Fork desde la Rama Objetivo con Revisores Requeridos

¡Asegúrese de haber creado un token de API y de haberlo establecido como un secreto del Repositorio llamado BENCHER_API_TOKEN antes de continuar! Navegue a Su Repo -> Configuración -> Secretos y variables -> Acciones -> Nuevo secreto del repositorio. Nombre el secreto BENCHER_API_TOKEN y establezca el valor del secreto para su token de API.

En GitHub Actions, los secretos no se pasan al ejecutor cuando un flujo de trabajo se activa desde un repositorio bifurcado. Por lo tanto, necesitarás usar una rama del mismo repositorio al agregar cualquiera de los flujos de trabajo a continuación a tu repositorio con una solicitud de extracción. Si intentas agregar Bencher con una solicitud de extracción desde un bifurcación, entonces el secreto BENCHER_API_TOKEN no estará disponible. ${{ secrets.BENCHER_API_TOKEN }} será una cadena vacía.

Rama Base

Una piedra angular del Benchmarking Continuo Estadístico es tener una línea de base histórica para tu rama base. Esta línea de base histórica puede ser utilizada para detectar regresiones de rendimiento en las 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. Crea un archivo de flujo de trabajo de GitHub Actions. (Ej: .github/workflows/base_benchmarks.yml)
2. Ejecutar en eventos de push a la rama main. Consulta la documentación de on de GitHub Actions y documentación de push de GitHub Actions para una visión completa. (Ej: on: push: branches: main)
3. Crea un trabajo de GitHub Actions. (Ej: jobs: benchmark_base_branch)
4. Establece el tipo de máquina en la que se ejecutará el trabajo. Consulta la documentación de runs-on de GitHub Actions para una visión completa. (Ej: runs-on: ubuntu-latest)
5. Haz checkout del código fuente de tu rama base. (Ej: uses: actions/checkout@v4)
6. Instala el CLI Bencher usando la GitHub Action. (Ej: uses: bencherdev/bencher@main)
7. Utiliza el subcomando CLI bencher run para ejecutar tus benchmarks de la rama main. Consulta el subcomando CLI bencher run para una visión completa. (Ej: bencher run)
8. Establece la opción --project al slug del Proyecto. Consulta los docs de --project para más detalles. (Ej: --project save-walter-white-1234abcd)
9. Establece la opción --token al secreto Repository BENCHER_API_TOKEN. Consulta los docs de --token para más detalles. (Ej: --token '${{ secrets.BENCHER_API_TOKEN }}')
10. Establece la opción --branch al nombre de la Rama. Consulta selección de rama para una visión completa. (Ej: --branch main)
11. Establece la opción --testbed al nombre de la Testbed. Probablemente debería coincidir con la máquina seleccionada en runs-on. Consulta los docs de --testbed para más detalles. (Ej: --testbed ubuntu-latest)
12. Establece la opción --adapter al adaptador de arnés de benchmarks deseado. Consulta adaptadores de arnés de benchmarks para una visión completa. (Ej: --adapter json)
13. Establece la bandera --err para fallar el comando si se genera una Alerta. Consulta Umbrales y Alertas para una visión completa. (Ej: --err)
14. Especifica los argumentos del comando de benchmark. Consulta comando de benchmark para una visión completa. (Ej: bencher mock)

Pull Requests

Para detectar una regresión de rendimiento en los Pull Requests (PR), necesitarás ejecutar tus benchmarks en los PRs. Si solo esperas tener PRs de ramas dentro del mismo repositorio, entonces simplemente puedes crear otro workflow para ejecutar on eventos de pull_request desde el mismo repositorio.

⚠️ ¡Esta solución solo funciona si todos los PRs son del mismo repositorio! Ver Pull Requests desde Forks a continuación.

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

1. Crea un archivo workflow de GitHub Actions. (ej: .github/workflows/pr_benchmarks.yml)

2. Ejecutar en eventos de pull_request:

   • opened - Se creó un pull request.
   • reopened - Se reabrió un pull request previamente cerrado.
   • edited - Se editó el título o el cuerpo de un pull request, o se cambió la rama base de un pull request.
   • synchronize - Se actualizó la rama principal de un pull request. Por ejemplo, la rama principal se actualizó a partir de la rama base o se empujaron nuevos commits a la rama principal.

   Ver la documentación de GitHub Actions on y la documentación de GitHub Actions pull_request para una visión completa. (ej: on: pull_request: types: [opened, reopened, edited, synchronize])

3. Crear un job de GitHub Actions. (ej: jobs: benchmark_pr_branch)

4. Ejecutar en eventos de pull_request solo si el pull request es del mismo repositorio. ⚠️ ¡NO REMUEVAS ESTA LÍNEA! Para manejar PRs de Forks ver Pull Requests desde Forks a continuación. (ej: if: github.event_name == 'pull_request' && github.event.pull_request.head.repo.full_name == github.repository)

5. Establecer los permisos para el GITHUB_TOKEN a write para pull-requests. Dependiendo de tu configuración en GitHub, esto puede no ser necesario. Pero para todas las organizaciones y repos personales creados después del 02 de febrero de 2023, este es el comportamiento predeterminado. Ver la documentación de GitHub para una visión completa. (ej: permissions: pull-requests: write)

6. Establecer el tipo de máquina en la que se ejecutará el job. Ver la documentación de GitHub Actions runs-on para una visión completa. (ej: runs-on: ubuntu-latest)

7. Checkout del código fuente de la rama PR. (ej: uses: actions/checkout@v4)

8. Instalar la CLI de Bencher usando la acción de GitHub. (ej: uses: bencherdev/bencher@main)

9. Utiliza el subcomando bencher run de la CLI para ejecutar tus benchmarks de la rama del pull request. Ver el subcomando bencher run de la CLI para una visión completa. (ej: bencher run)

10. Establecer la opción --project al slug del Proyecto. Ver la documentación de --project para más detalles. (ej: --project save-walter-white-1234abcd)

11. Establecer la opción --token al secreto del Repositorio BENCHER_API_TOKEN. Ver la documentación de --token para más detalles. (ej: --token '${{ secrets.BENCHER_API_TOKEN }}')

12. Establecer la opción --branch al nombre de la rama PR usando el contexto github de GitHub Actions. Ver selección de rama para una visión completa. (ej: --branch '${{ github.head_ref }}')

13. Establecer la opción --branch-start-point al punto de inicio de la rama base del PR usando el contexto github de GitHub Actions. Ver selección de rama para una visión completa. (ej: --branch-start-point '${{ github.base_ref }}')

14. Establecer la opción --branch-start-point-hash al hash del punto de inicio de la rama base del PR usando el evento pull_request de GitHub Actions. Ver selección de rama para una visión completa. (ej: --branch-start-point-hash '${{ github.event.pull_request.base.sha }}')

15. Establecer el flag --branch-reset para siempre resetear la rama al punto de inicio. Esto evitará la deriva de datos de benchmark. Ver selección de rama para una visión completa. (ej: --branch-reset)

16. Establecer la opción --testbed al nombre del Testbed. Esto debería coincidir con la máquina seleccionada en runs-on. Ver la documentación de --testbed para más detalles. (ej: --testbed ubuntu-latest)

17. Establecer la opción --adapter al adaptador de harness de benchmark deseado. Ver adaptadores de harness de benchmark para una visión completa. (ej: --adapter json)

18. Establecer el flag --err para fallar el comando si se genera una Alerta. Ver Umbral y Alertas para una visión completa. (ej: --err)

19. Establecer la opción --github-actions al token de autenticación de la API de GitHub para publicar resultados como un comentario en el Pull Request usando la variable de entorno GITHUB_TOKEN de GitHub Actions. Ver la documentación de --github-actions para más detalles. (ej: --github-actions '${{ secrets.GITHUB_TOKEN }}')

20. Especificar los argumentos de comando de benchmark. Ver comando de benchmark para una visión completa. (ej: bencher mock)

Solicitudes de Extracción desde Bifurcaciones

Si planeas aceptar solicitudes de extracción de bifurcaciones, como suele ser el caso en proyectos de código abierto públicos, entonces necesitarás manejar las cosas de manera un poco diferente. Por razones de seguridad, secretos como tu BENCHER_API_TOKEN y el GITHUB_TOKEN no están disponibles en GitHub Actions para PRs de bifurcaciones. Es decir, si un contribuidor externo abre una PR desde una bifurcación el ejemplo anterior no funcionará. Hay dos opciones para PRs de bifurcaciones:

• ⛑️ Más seguro: Benchmark Fork PR and Upload from Default Branch
• ⚠️ Más riesgoso: Benchmark Fork PR from Target Branch with Required Reviewers

Consulta este artículo de GitHub Security Lab y este blog post sobre la prevención de pwn requests para una visión completa.

Benchmark Fork PR y Subir desde la Rama Predeterminada

Esta es la manera segura y sugerida para agregar Benchmarking Continuo a pull requests de forks. Se requieren dos flujos de trabajo separados. El primer flujo de trabajo ejecuta y almacena en caché los resultados del benchmark en el contexto de pull_request. Ningún secreto como tu BENCHER_API_TOKEN y el GITHUB_TOKEN están disponibles ahí. Luego, un segundo flujo de trabajo descarga los resultados del benchmark almacenados en caché en el contexto de workflow_run y los sube a Bencher. Esto funciona porque workflow_run se ejecuta en el contexto de la rama predeterminada del repositorio, donde secretos como tu BENCHER_API_TOKEN y el GITHUB_TOKEN están disponibles. El número del pull request, la rama de origen y la rama base utilizadas en el flujo de trabajo inicial de pull_request también deben ser pasadas explícitamente al flujo de trabajo de workflow_run ya que no están disponibles ahí. Estos flujos de trabajo solo se ejecutarán si existen en la rama predeterminada. Consulta usando datos del flujo de trabajo de activación para una visión 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 }}

1. Crea un primer archivo de workflow de GitHub Actions. (ej: .github/workflows/run_fork_pr_benchmarks.yml)

2. Nombra este flujo de trabajo para que pueda ser referenciado por el segundo flujo de trabajo. (ej: name: Run and Cache Benchmarks)

3. Ejecuta en eventos de pull_request:

   • opened - Se creó un pull request.
   • reopened - Se reabrió un pull request cerrado previamente.
   • edited - Se editó el título o el cuerpo de un pull request, o se cambió la rama base de un pull request.
   • synchronize - Se actualizó la rama de origen de un pull request. Por ejemplo, la rama de origen se actualizó desde la rama base o se empujaron nuevos commits a la rama de origen.

   Consulta la documentación de on de GitHub Actions y la documentación de pull_request de GitHub Actions para una visión completa. (ej: on: pull_request: types: [opened, reopened, edited, synchronize])

4. Crea un job de GitHub Actions. (ej: jobs: benchmark_fork_pr_branch)

5. Configura el tipo de máquina en la que se ejecutará el trabajo. Consulta la documentación de runs-on de GitHub Actions para una visión completa. (ej: runs-on: ubuntu-latest)

6. Haz checkout del código fuente de la rama del fork PR. (ej: uses: actions/checkout@v4)

7. Ejecuta tus benchmarks y guarda los resultados en un archivo. (ej: /bin/echo '{ ... }' > benchmark_results.json)

8. Sube el archivo de resultados del benchmark como un artefacto. (ej: uses: actions/upload-artifact@v4)

9. Sube el objeto del evento pull_request como un artefacto. (ej: 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"

1. Crea un primer archivo de workflow de GitHub Actions. (ej: .github/workflows/track_fork_pr_benchmarks.yml)
2. Nombra este segundo flujo de trabajo. (ej: name: Track Benchmarks with Bencher)
3. Encadena los dos flujos de trabajo con el evento workflow_run. (ej: on: workflow_run: ...)
4. Crea un job de GitHub Actions. (ej: jobs: track_fork_pr_branch)
5. Ejecuta este trabajo solo si la conclusión del flujo de trabajo anterior fue un éxito usando el evento workflow_run de GitHub Actions. (ej: if: github.event.workflow_run.conclusion == 'success')
6. Configura el tipo de máquina en la que se ejecutará el trabajo. Consulta la documentación de runs-on de GitHub Actions para una visión completa. (ej: runs-on: ubuntu-latest)
7. Configura los nombres de los archivos de resultados del benchmark y del objeto del evento pull_request como variables de entorno. (ej: env: ...)
8. Descarga los resultados del benchmark almacenados en caché y el evento pull_request. (ej: uses: actions/github-script@v6)
9. Extrae los resultados del benchmark almacenados en caché y el evento pull_request. (ej: unzip ...)
10. Exporta los datos necesarios del evento pull_request como variables de entorno. (ej: core.exportVariable(...))
11. Instala el CLI de Bencher usando la acción de GitHub. (ej: uses: bencherdev/bencher@main)
12. Usa el subcomando del CLI bencher run para seguir los benchmarks de tu rama de fork pull. Consulta el subcomando bencher run del CLI para una visión completa. (ej: bencher run)
13. Configura la opción --project con el slug del Proyecto. Consulta la documentación de la opción --project para más detalles. (ej: --project save-walter-white-1234abcd)
14. Configura la opción --token con el secreto del Repositorio BENCHER_API_TOKEN. Consulta la documentación de la opción --token para más detalles. (ej: --token '${{ secrets.BENCHER_API_TOKEN }}')
15. Configura la opción --branch con el número formateado del fork PR usando el evento pull_request de GitHub Actions. Consulta la selección de ramas para una visión completa. (ej: --branch '${{ env.PR_HEAD }}')
16. Configura la opción --branch-start-point con el punto de inicio de la rama base del fork PR usando el evento pull_request de GitHub Actions. Consulta la selección de ramas para una visión completa. (ej: --branch-start-point '${{ env.PR_BASE }}')
17. Configura la opción --branch-start-point-hash con el hash del punto de inicio de la rama base del fork PR usando el evento pull_request de GitHub Actions. Consulta la selección de ramas para una visión completa. (ej: --branch-start-point-hash '${{ env.PR_BASE_SHA }}')
18. Configura el flag --branch-reset para siempre reiniciar la rama al punto de inicio. Esto evitará la deriva de datos del benchmark. Consulta la selección de ramas para una visión completa. (ej: --branch-reset)
19. Configura la opción --testbed con el nombre del Testbed. Esto probablemente debería coincidir con la máquina seleccionada en runs-on. Consulta la documentación de la opción --tested para más detalles. (ej: --testbed ubuntu-latest)
20. Configura la opción --adapter con el adaptador deseado del arnés de benchmark. Consulta los adaptadores del arnés de benchmark para una visión completa. (ej: --adapter json)
21. Configura el flag --err para fallar el comando si se genera una Alerta. Consulta Threshold & Alerts para una visión completa. (ej: --err)
22. Configura la opción --github-actions con el token de autenticación de la API de GitHub para publicar resultados como un comentario en el Pull Request usando la variable de entorno GITHUB_TOKEN de GitHub Actions. Consulta la documentación de la opción --github-actions para más detalles. (ej: --github-actions '${{ secrets.GITHUB_TOKEN }}')
23. Configura la opción --ci-number con el número del pull request. Consulta la documentación de la opción --ci-number para más detalles. (ej: --ci-number '${{ env.PR_NUMBER }}')
24. Configura la opción --file con la ruta del archivo de resultados del benchmark. Consulta el comando del benchmark para una visión completa. (ej: --file "$BENCHMARK_RESULTS")

Evaluar PRs de Fork desde la Rama Objetivo con Revisores Requeridos

Para garantizar que el código de una solicitud de extracción (pull request) originada de un fork sea seguro, esta Acción de GitHub verifica si el fork proviene de otro repositorio. Si el fork proviene de otro repositorio, entonces necesitará ser revisado.

⚠️ Es muy, muy importante revisar minuciosamente cada PR de fork antes de aprobarlo! ¡No hacerlo podría resultar en una solicitud comprometida!

Si prefieres no tener esa responsabilidad, consulta Evaluar PRs de Fork y Subir desde la Rama Predeterminada arriba.

Para configurar este flujo de trabajo, necesitas crear dos Entornos de GitHub Actions. Navega a Tu Repositorio -> Configuración -> Entornos -> Nuevo entorno. Crea dos nuevos entornos, internal y external. El entorno internal no debería tener Reglas de protección de despliegue. Sin embargo, el entorno external debería tener Revisores requeridos establecidos para aquellos de confianza que revisarán los PRs de fork antes de evaluarlos. Consulta esta publicación en el blog para una visión general completa.

Esta configuración funciona porque pull_request_target se ejecuta en el contexto de la rama objetivo del pull request, donde los secretos como tu BENCHER_API_TOKEN y el GITHUB_TOKEN están disponibles. Por lo tanto, este flujo de trabajo solo se ejecutará si existe en la rama objetivo. Evita configurar cualquier secreto como variables de entorno, tales como GITHUB_TOKEN y BENCHER_API_TOKEN. En su lugar, pasa explícitamente tus secretos a 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

1. Crea un archivo de workflow de GitHub Actions. (ej: .github/workflows/pr_target_benchmarks.yml)

2. Ejecuta en eventos de pull_request:

   • opened - Se creó un pull request.
   • reopened - Se reabrió un pull request previamente cerrado.
   • edited - Se editó el título o cuerpo de un pull request, o se cambió la rama base de un pull request.
   • synchronize - Se actualizó la rama principal de un pull request. Por ejemplo, la rama principal se actualizó desde la rama base o se enviaron nuevos commits a la rama principal.

   Consulta la documentación de GitHub Actions sobre on y la documentación de GitHub Actions sobre pull_request para una visión completa. (ej: on: pull_request: types: [opened, reopened, edited, synchronize])

3. Crea un primer job de GitHub Actions para verificar si el flujo de trabajo requiere revisión. (ej: jobs: fork_pr_requires_review)

4. Configura el environment a internal si y solo si el pull request es del mismo repositorio. De lo contrario, configura el environment a external, lo que requerirá la aprobación de un revisor para continuar. ⚠️ ¡NO ELIMINES ESTA LÍNEA! (ej: environment: ${{ (github.event.pull_request.head.repo.full_name == github.repository && 'internal') || 'external' }})

5. Crea un segundo job de GitHub Actions para ejecutar tus benchmarks. (ej: benchmark_fork_pr_branch)

6. Haz que el job benchmark_fork_pr_branch necesite el job fork_pr_requires_review para ejecutarse. ⚠️ ¡NO ELIMINES ESTA LÍNEA! Consulta la documentación de GitHub Actions sobre needs para una visión completa. (ej: needs: fork_pr_requires_review)

7. Configura el tipo de máquina en la que se ejecutará el job. Consulta la documentación de GitHub Actions sobre runs-on para una visión completa. (ej: runs-on: ubuntu-latest)

8. Haz checkout del código fuente del PR del fork. Ya que pull_request_target se ejecuta en el contexto de la rama objetivo del pull request, aún necesitas hacer checkout de la rama del pull request. (ej: uses: actions/checkout@v4)

   • Especifica el repositorio del PR del fork (ej: repository: ${{ github.event.pull_request.head.repo.full_name }})
   • Especifica el hash del PR del fork (ej: ref: ${{ github.event.pull_request.head.sha }})
   • No continúes usando tus credenciales de git (ej: persist-credentials: false)

9. Instala la CLI de Bencher usando la Acción de GitHub. (ej: uses: bencherdev/bencher@main)

10. Usa el subcomando de CLI bencher run para ejecutar tus benchmarks en la rama del pull request del fork. Consulta el subcomando bencher run de CLI para una visión completa. (ej: bencher run)

11. Configura la opción --project con el slug del Proyecto. Consulta los documentos de --project para más detalles. (ej: --project save-walter-white-1234abcd)

12. Configura la opción --token con el secreto del repositorio BENCHER_API_TOKEN. Consulta los documentos de --token para más detalles. (ej: --token '${{ secrets.BENCHER_API_TOKEN }}')

13. Configura la opción --branch con el número de PR del fork formateado usando el evento pull_request de GitHub Actions. Consulta la selección de rama para una visión completa. (ej: --branch '${{ github.event.number }}/merge')

14. Configura la opción --branch-start-point con el punto de inicio de la rama base del PR del fork usando el contexto de GitHub Actions github. Consulta la selección de rama para una visión completa. (ej: --branch-start-point '${{ github.base_ref }}')

15. Configura la opción --branch-start-point-hash con el hash del punto de inicio de la rama base del PR del fork usando el evento pull_request de GitHub Actions. Consulta la selección de rama para una visión completa. (ej: --branch-start-point-hash '${{ github.event.pull_request.base.sha }}')

16. Configura el flag --branch-reset para que siempre se reinicie la rama al punto de inicio. Esto evitará la deriva de datos de benchmark. Consulta la selección de rama para una visión completa. (ej: --branch-reset)

17. Configura la opción --testbed con el nombre del Testbed. Esto debería coincidir probablemente con la máquina seleccionada en runs-on. Consulta los documentos de --testbed para más detalles. (ej: --testbed ubuntu-latest)

18. Configura la opción --adapter con el adaptador del arnés de benchmark deseado. Consulta los adaptadores del arnés de benchmark para una visión completa. (ej: --adapter json)

19. Configura el flag --err para que falle el comando si se genera una Alerta. Consulta Threshold & Alerts para una visión completa. (ej: --err)

20. Configura la opción --github-actions con el token de autenticación de la API de GitHub para publicar resultados como un comentario en el Pull Request usando la variable de entorno GITHUB_TOKEN de GitHub Actions. Consulta los documentos de --github-actions para más detalles. (ej: --github-actions '${{ secrets.GITHUB_TOKEN }}')

21. Especifica los argumentos del comando de benchmark. Consulta el comando de benchmark para una visión completa. (ej: bencher mock)

🐰 ¡Felicidades! ¡Has aprendido cómo usar Bencher en GitHub Actions! 🎉

Continúa: Visión General del Benchmarking ➡