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 aSu Repo -> Configuración -> Secretos y variables -> Acciones -> Nuevo secreto del repositorio
. Nombre el secretoBENCHER_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.
- Crea un archivo de
flujo de trabajo
de GitHub Actions. (Ej:.github/workflows/base_benchmarks.yml
) - Ejecutar en eventos de
push
a la ramamain
. Consulta la documentación deon
de GitHub Actions y documentación depush
de GitHub Actions para una visión completa. (Ej:on: push: branches: main
) - Crea un
trabajo
de GitHub Actions. (Ej:jobs: benchmark_base_branch
) - 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
) - Haz checkout del código fuente de tu rama base.
(Ej:
uses: actions/checkout@v4
) - Instala el CLI Bencher usando la GitHub Action.
(Ej:
uses: bencherdev/bencher@main
) - Utiliza el subcomando CLI
bencher run
para ejecutar tus benchmarks de la ramamain
. Consulta el subcomando CLIbencher run
para una visión completa. (Ej:bencher run
) - Establece la opción
--project
al slug del Proyecto. Consulta los docs de--project
para más detalles. (Ej:--project save-walter-white-1234abcd
) - Establece la opción
--token
al secreto RepositoryBENCHER_API_TOKEN
. Consulta los docs de--token
para más detalles. (Ej:--token '${{ secrets.BENCHER_API_TOKEN }}'
) - Establece la opción
--branch
al nombre de la Rama. Consulta selección de rama para una visión completa. (Ej:--branch main
) - Establece la opción
--testbed
al nombre de la Testbed. Probablemente debería coincidir con la máquina seleccionada enruns-on
. Consulta los docs de--testbed
para más detalles. (Ej:--testbed ubuntu-latest
) - 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
) - Establece la bandera
--err
para fallar el comando si se genera una Alerta. Consulta Umbrales y Alertas para una visión completa. (Ej:--err
) - 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.
-
Crea un archivo de
workflow
de GitHub Actions. (ej:.github/workflows/pr_benchmarks.yml
) -
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 Actionspull_request
para una visión completa. (ej:on: pull_request: types: [opened, reopened, edited, synchronize]
) -
Crea un
job
de GitHub Actions. (ej:jobs: benchmark_pr_branch
) -
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
) -
Establece los permisos para el
GITHUB_TOKEN
awrite
parapull-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
) -
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
) -
Extrae el código fuente de la rama PR. (ej:
uses: actions/checkout@v4
) -
Instala el CLI de Bencher utilizando la Acción de GitHub. (ej:
uses: bencherdev/bencher@main
) -
Utiliza el subcomando de CLI
bencher run
para ejecutar las pruebas de rendimiento de tu rama de solicitud de extracción. Consulta el subcomandobencher run
CLI para una visión completa. (ej:bencher run
) -
Establece la opción
--project
al slug del Proyecto. Consulta los documentos de--project
para más detalles. (ej:--project save-walter-white-1234abcd
) -
Establece la opción
--token
al secreto del RepositorioBENCHER_API_TOKEN
. Consulta los documentos de--token
para más detalles. (ej:--token '${{ secrets.BENCHER_API_TOKEN }}'
) -
Establece la opción
--branch
al nombre de la rama PR usando el contexto de GitHub Actionsgithub
. Consulta selección de rama para una visión completa. (ej:--branch '${{ github.head_ref }}'
) -
Establece la opción
--branch-start-point
al punto de inicio de la Rama base PR usando el contexto de GitHub Actionsgithub
. Consulta selección de rama para una visión completa. (ej:--branch-start-point '${{ github.base_ref }}'
) -
Establece la opción
--branch-start-point-hash
al hash del punto de inicio de la Rama base PR usando el evento de GitHub Actionspull_request
. Consulta selección de rama para una visión completa. (ej:--branch-start-point-hash '${{ github.event.pull_request.base.sha }}'
) -
Establece la opción
--testbed
al nombre del Banco de pruebas. Esto probablemente debería coincidir con la máquina seleccionada enruns-on
. Consulta los documentos de--tested
para más detalles. (ej:--testbed ubuntu-latest
) -
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
) -
Establece la bandera
--err
para fallar el comando si se genera una Alerta. Consulta Umbrales y Alertas para una visión completa. (ej:--err
) -
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 ActionsGITHUB_TOKEN
. Consulta los documentos de--github-actions
para más detalles. (ej:--github-actions '${{ secrets.GITHUB_TOKEN }}'
) -
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:
- ⛑️ 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 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.
-
Crea un archivo de
workflow
de GitHub Actions. (ej:.github/workflows/run_fork_pr_benchmarks.yml
) -
Nombra este flujo de trabajo para que pueda ser referenciado por el segundo flujo de trabajo. (ej:
name: Run and Cache Benchmarks
) -
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 Actionspull_request
para una descripción completa. (ej:on: pull_request: types: [opened, reopened, edited, synchronize]
) -
Crea un
job
de GitHub Actions. (ej:jobs: benchmark_fork_pr_branch
) -
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
) -
Haz checkout del código fuente de la rama PR del fork. (ej:
uses: actions/checkout@v4
) -
Ejecuta tus benchmarks y guarda los resultados en un archivo. (ej:
/bin/echo '{ ... }' > benchmark_results.json
) -
Sube el archivo de resultados de benchmarks como un artefacto. (ej:
uses: actions/upload-artifact@v4
) -
Sube el objeto del evento
pull_request
como un artefacto. (ej:uses: actions/upload-artifact@v4
)
- Crea un archivo de
workflow
de GitHub Actions. (ej:.github/workflows/track_fork_pr_benchmarks.yml
) - Nombra este segundo flujo de trabajo.
(ej:
name: Track Benchmarks with Bencher
) - Encadena los dos flujos de trabajo con
el evento
workflow_run
. (ej:on: workflow_run: ...
) - Crea un
job
de GitHub Actions. (ej:jobs: track_fork_pr_branch
) - 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'
) - 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
) - Establece los nombres de archivo de los resultados de benchmarks y el objeto del evento
pull_request
como variables de entorno. (ej:env: ...
) - Descarga los resultados del benchmark almacenados en caché y el evento
pull_request
. (ej:uses: actions/github-script@v6
) - Extrae los resultados de benchmarks almacenados en caché y el evento
pull_request
. (ej:unzip ...
) - Exporta los datos necesarios del evento
pull_request
como variables de entorno. (ej:core.exportVariable(...)
) - Instala la CLI de Bencher usando la acción de GitHub.
(ej:
uses: bencherdev/bencher@main
) - Usa el subcomando de la CLI
bencher run
para rastrear los benchmarks de tu rama de pull request de fork. Consulta el subcomandobencher run
de la CLI para una descripción completa. (ej:bencher run
) - 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
) - Establece la opción
--token
al secreto del repositorioBENCHER_API_TOKEN
. Consulta los docs de la opción--token
para más detalles. (ej:--token '${{ secrets.BENCHER_API_TOKEN }}'
) - Establece la opción
--branch
al número formateado de la PR del fork usando el eventopull_request
de GitHub Actions. Consulta selección de la rama para una descripción completa. (ej:--branch '${{ env.PR_HEAD }}'
) - Establece la opción
--branch-start-point
al punto de inicio de la rama base de la PR del fork usando el eventopull_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 }}'
) - 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 eventopull_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 }}'
) - Establece la opción
--testbed
al nombre del Testbed. Esto probablemente coincidirá con la máquina seleccionada enruns-on
. Consulta los docs de la opción--testbed
para más detalles. (ej:--testbed ubuntu-latest
) - 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
) - Establece la bandera
--err
para fallar el comando si se genera una Alerta. Consulta Umbrales y Alertas para una descripción completa. (ej:--err
) - 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 entornoGITHUB_TOKEN
de GitHub Actions. Consulta los docs de la opción--github-actions
para más detalles. (ej:--github-actions '${{ secrets.GITHUB_TOKEN }}'
) - 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 }}'
) - 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
.
-
Crea un archivo
workflow
de GitHub Actions. (ej:.github/workflows/pr_target_benchmarks.yml
) -
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 Actionspull_request
para una visión general completa. (ej:on: pull_request: types: [opened, reopened, edited, synchronize]
) -
Crea un primer trabajo
job
de GitHub Actions para verificar si el flujo de trabajo requiere revisión. (ej:jobs: fork_pr_requires_review
) -
Establece el
entorno
ainternal
si y solo si la pull request es del mismo repositorio. De lo contrario, establece elentorno
aexternal
, 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' }}
) -
Crea un segundo trabajo
job
de GitHub Actions para ejecutar tus comparaciones de rendimiento. (ej:benchmark_fork_pr_branch
) -
El trabajo
benchmark_fork_pr_branch
necesita el trabajofork_pr_requires_review
para poder ejecutarse. ⚠️ ¡NO ELIMINES ESTA LÍNEA! Consulta la documentación GitHub Actionsneeds
para una visión general completa. (ej:needs: fork_pr_requires_review
) -
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
) -
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
)
- Especifica el repositorio de la PR de fork (ej:
-
Instala la CLI de Bencher usando la GitHub Action. (ej:
uses: bencherdev/bencher@main
) -
Usa el subcomando de CLI
bencher run
para ejecutar tus comparaciones de rendimiento de la rama de fork pull. Consulta el subcomando de CLIbencher run
para una visión general completa. (ej:bencher run
) -
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
) -
Establece la opción
--token
al secreto RepositorioBENCHER_API_TOKEN
. Consulta la documentación de--token
para más detalles. (ej:--token '${{ secrets.BENCHER_API_TOKEN }}'
) -
Establece la opción
--branch
al número de PR de fork formateado usando el eventopull_request
de GitHub Actions. Consulta selección de rama para una visión general completa. (ej:--branch '${{ github.event.number }}/merge'
) -
Establece la opción
--branch-start-point
al punto de inicio de la rama base de la PR de fork usando el contextogithub
de GitHub Actions. Consulta selección de rama para una visión general completa. (ej:--branch-start-point '${{ github.base_ref }}'
) -
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 eventopull_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 }}'
) -
Establece la opción
--testbed
al nombre del Entorno de prueba. Esto probablemente coincidirá con la máquina seleccionada enruns-on
. Consulta la documentación de--tested
para más detalles. (ej:--testbed ubuntu-latest
) -
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
) -
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
) -
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 entornoGITHUB_TOKEN
de GitHub Actions. Consulta la documentación de--github-actions
para más detalles. (ej:--github-actions '${{ secrets.GITHUB_TOKEN }}'
) -
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! 🎉