Cómo usar Bencher en GitHub Actions


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

🐰 ¡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.

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)

Solicitudes de Extracción (Pull Requests)

Para detectar la regresión de rendimiento en las Solicitudes de Extracción, necesitarás ejecutar tus pruebas de rendimiento en los PRs. Si solo esperas tener PRs de ramas dentro del mismo repositorio, entonces puedes simplemente crear otro flujo de trabajo para ejecutar on eventos de pull_request desde el mismo repositorio.

⚠️ ¡Esta solución solo funciona si todos los PRs son del mismo repositorio! Consulta Solicitudes de Extracción desde Bifurcaciones (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 }}' \
--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_benchmarks.yml)

  2. Ejecuta en eventos de pull_request:

    • opened - Se creó una solicitud de extracción.
    • reopened - Una solicitud de extracción cerrada previamente fue reabierta.
    • edited - El título o cuerpo de una solicitud de extracción fue editado, o se cambió la rama base de una solicitud de extracción.
    • synchronize - La rama principal de una solicitud de extracción fue actualizada. Por ejemplo, la rama principal fue actualizada desde la rama base o se empujaron nuevos commits a la rama principal.

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

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

  4. Ejecutará en eventos de pull_request si y solo si la solicitud de extracción es del mismo repositorio. ⚠️ ¡NO ELIMINES ESTA LÍNEA! Para manejar PRs de Forks consulta Solicitudes de Extracción desde Bifurcaciones (Forks) a continuación. (ej: if: github.event_name == 'pull_request' && github.event.pull_request.head.repo.full_name == github.repository)

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

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

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

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

  9. Utiliza el subcomando de CLI bencher run para ejecutar las pruebas de rendimiento de tu rama de solicitud de extracción. Consulta el subcomando bencher run CLI para una visión completa. (ej: bencher run)

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

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

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

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

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

  15. Establece la opción --testbed al nombre del Banco de pruebas. Esto probablemente debería coincidir con la máquina seleccionada en runs-on. Consulta los documentos de --tested para más detalles. (ej: --testbed ubuntu-latest)

  16. Establece la opción --adapter al adaptador del arnés de pruebas deseado. Consulta adaptadores del arnés de pruebas para una visión completa. (ej: --adapter json)

  17. Establece la bandera --err para fallar el comando si se genera una Alerta. Consulta Umbrales y Alertas para una visión completa. (ej: --err)

  18. Establece la opción --github-actions al token de autenticación API de GitHub para publicar resultados como un comentario en la Solicitud de Extracción usando la variable de entorno de GitHub Actions GITHUB_TOKEN. Consulta los documentos de --github-actions para más detalles. (ej: --github-actions '${{ secrets.GITHUB_TOKEN }}')

  19. Especifica los argumentos del comando de prueba. Consulta comando de prueba 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:

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 de Fork PR y Carga desde la Rama por Defecto

Esta es la manera segura y sugerida de añadir Benchmarking Continuo a las pull requests de forks. Requiere 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. No se encuentran disponibles secretos como tu BENCHER_API_TOKEN y el GITHUB_TOKEN. Luego, un segundo flujo de trabajo descarga los resultados del benchmark almacenados en caché en el contexto de workflow_run y los carga a Bencher. Esto funciona porque workflow_run se ejecuta en el contexto de la rama por defecto del repositorio, donde secretos como tu BENCHER_API_TOKEN y el GITHUB_TOKEN están disponibles. El número de la pull request, la rama base y la rama head utilizadas en el flujo de trabajo inicial de pull_request deben también pasarse explícitamente al flujo de trabajo de workflow_run ya que no están disponibles allí. Estos flujos de trabajo solo se ejecutarán si existen en la rama por defecto. Consulta usando datos del flujo de trabajo que activa para una descripció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 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ó una pull request.
    • reopened - Una pull request cerrada previamente fue reabierta.
    • edited - El título o cuerpo de una pull request fue editado, o la rama base de una pull request fue cambiada.
    • synchronize - La rama head de una pull request fue actualizada. Por ejemplo, la rama head fue actualizada desde la rama base o nuevos commits fueron empujados a la rama head.

    Consulta la documentación de GitHub Actions on y GitHub Actions pull_request para una descripció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. Establece el tipo de máquina en la que el trabajo se ejecutará. Consulta la documentación de GitHub Actions runs-on para una descripción completa. (ej: runs-on: ubuntu-latest)

  6. Haz checkout del código fuente de la rama PR del fork. (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 de benchmarks 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 }}' \
--testbed ubuntu-latest \
--adapter json \
--err \
--github-actions '${{ secrets.GITHUB_TOKEN }}' \
--ci-number '${{ env.PR_NUMBER }}' \
--file "$BENCHMARK_RESULTS"
  1. Crea un 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. Solo ejecuta este trabajo 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. Establece el tipo de máquina en la que el trabajo se ejecutará. Consulta la documentación de GitHub Actions runs-on para una descripción completa. (ej: runs-on: ubuntu-latest)
  7. Establece los nombres de archivo de los resultados de benchmarks y el 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 de benchmarks 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 la CLI de Bencher usando la acción de GitHub. (ej: uses: bencherdev/bencher@main)
  12. Usa el subcomando de la CLI bencher run para rastrear los benchmarks de tu rama de pull request de fork. Consulta el subcomando bencher run de la CLI para una descripción completa. (ej: bencher run)
  13. Establece la opción --project al slug del Proyecto. Consulta los docs de la opción --project para más detalles. (ej: --project save-walter-white-1234abcd)
  14. Establece la opción --token al secreto del repositorio BENCHER_API_TOKEN. Consulta los docs de la opción --token para más detalles. (ej: --token '${{ secrets.BENCHER_API_TOKEN }}')
  15. Establece la opción --branch al número formateado de la PR del fork usando el evento pull_request de GitHub Actions. Consulta selección de la rama para una descripción completa. (ej: --branch '${{ env.PR_HEAD }}')
  16. Establece la opción --branch-start-point al punto de inicio de la rama base de la PR del fork usando el evento pull_request de GitHub Actions. Consulta selección del punto de inicio de la rama para una descripción completa. (ej: --branch-start-point '${{ env.PR_BASE }}')
  17. Establece la opción --branch-start-point-hash al hash del punto de inicio de la rama base de la PR del fork usando el evento pull_request de GitHub Actions. Consulta selección del hash del punto de inicio de la rama para una descripción completa. (ej: --branch-start-point-hash '${{ env.PR_BASE_SHA }}')
  18. Establece la opción --testbed al nombre del Testbed. Esto probablemente coincidirá con la máquina seleccionada en runs-on. Consulta los docs de la opción --testbed para más detalles. (ej: --testbed ubuntu-latest)
  19. Establece la opción --adapter al adaptador deseado del harness de benchmarks. Consulta adaptadores del harness de benchmarks para una descripción completa. (ej: --adapter json)
  20. Establece la bandera --err para fallar el comando si se genera una Alerta. Consulta Umbrales y Alertas para una descripción completa. (ej: --err)
  21. Establece la opción --github-actions al token de autenticación de la API de GitHub para publicar resultados como un comentario en la Pull Request usando la variable de entorno GITHUB_TOKEN de GitHub Actions. Consulta los docs de la opción --github-actions para más detalles. (ej: --github-actions '${{ secrets.GITHUB_TOKEN }}')
  22. Establece la opción --ci-number al número de la pull request. Consulta los docs de la opción --ci-number para más detalles. (ej: --ci-number '${{ env.PR_NUMBER }}')
  23. Establece la opción --file al camino del archivo de resultados de benchmarks. Consulta comando de benchmark para una descripción completa. (ej: --file "$BENCHMARK_RESULTS")

Comparar PR de Fork con Rama Objetivo Requiriendo Revisores

Para garantizar que el código de una pull request de un fork es seguro, esta GitHub Action verifica si el fork proviene de otro repositorio. Si el fork proviene de otro repositorio, entonces necesitará ser revisado.

⚠️ Es muy, muy importante revisar exhaustivamente cada PR de un fork antes de aprobarlo! No hacerlo podría resultar en una solicitud de compromiso!

Si prefieres evitar tener eso sobre tu cabeza, consulta [Comparar PR de Fork y Subir desde Rama por Defecto][benchmark fork pr and upload from default branch] 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 para revisar los PR de forks antes de compararlos. Consulta esta publicación de blog para una visión general completa.

Esta configuración funciona porque pull_request_target se ejecuta en el contexto de la rama objetivo de la solicitud de extracción, donde 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 establecer cualquier secreto como variables de entorno, como GITHUB_TOKEN y BENCHER_API_TOKEN. En su lugar, pasa tus secretos explícitamente 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 }}' \
--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_target_benchmarks.yml)

  2. Ejecuta en eventos pull_request:

    • opened - Una pull request fue creada.
    • reopened - Una pull request cerrada previamente fue reabierta.
    • edited - El título o cuerpo de una pull request fue editado, o la rama base de una pull request fue cambiada.
    • synchronize - La rama head de una pull request fue actualizada. Por ejemplo, la rama head fue actualizada desde la rama base o nuevos commits fueron empujados a la rama head.

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

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

  4. Establece el entorno a internal si y solo si la pull request es del mismo repositorio. De lo contrario, establece el entorno 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 trabajo job de GitHub Actions para ejecutar tus comparaciones de rendimiento. (ej: benchmark_fork_pr_branch)

  6. El trabajo benchmark_fork_pr_branch necesita el trabajo fork_pr_requires_review para poder ejecutarse. ⚠️ ¡NO ELIMINES ESTA LÍNEA! Consulta la documentación GitHub Actions needs para una visión general completa. (ej: needs: fork_pr_requires_review)

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

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

    • Especifica el repositorio de la PR de fork (ej: repository: ${{ github.event.pull_request.head.repo.full_name }})
    • Especifica el hash de la PR de fork (ej: ref: ${{ github.event.pull_request.head.sha }})
    • No persistas tus credenciales de git (ej: persist-credentials: false)
  9. Instala la CLI de Bencher usando la GitHub Action. (ej: uses: bencherdev/bencher@main)

  10. Usa el subcomando de CLI bencher run para ejecutar tus comparaciones de rendimiento de la rama de fork pull. Consulta el subcomando de CLI bencher run para una visión general completa. (ej: bencher run)

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

  12. Establece la opción --token al secreto Repositorio BENCHER_API_TOKEN. Consulta la documentación de --token para más detalles. (ej: --token '${{ secrets.BENCHER_API_TOKEN }}')

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

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

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

  16. Establece la opción --testbed al nombre del Entorno de prueba. Esto probablemente coincidirá con la máquina seleccionada en runs-on. Consulta la documentación de --tested para más detalles. (ej: --testbed ubuntu-latest)

  17. Establece la opción --adapter al adaptador de arnés de comparación deseado. Consulta adaptadores de arnés de comparación para una visión general completa. (ej: --adapter json)

  18. Establece la bandera --err para fallar el comando si se genera una Alerta. Consulta Umbrales y Alertas para una visión general completa. (ej: --err)

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

  20. Especifica los argumentos del comando de comparación. Consulta comando de comparación para una visión general completa. (ej: bencher mock)



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


Continúa: Visión General del Benchmarking ➡

🤖 Este documento fue generado automáticamente por OpenAI GPT-4. Puede que no sea exacto y contenga errores. Si encuentra algún error, abra un problema en GitHub.


Published: Fri, October 27, 2023 at 8:40:00 AM UTC | Last Updated: Mon, April 1, 2024 at 7:00:00 AM UTC