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.
- 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
)
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.
-
Crea un archivo
workflow
de GitHub Actions. (ej:.github/workflows/pr_benchmarks.yml
) -
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 Actionspull_request
para una visión completa. (ej:on: pull_request: types: [opened, reopened, edited, synchronize]
) -
Crear un
job
de GitHub Actions. (ej:jobs: benchmark_pr_branch
) -
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
) -
Establecer los permisos para el
GITHUB_TOKEN
awrite
parapull-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
) -
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
) -
Checkout del código fuente de la rama PR. (ej:
uses: actions/checkout@v4
) -
Instalar la CLI de Bencher usando la acción de GitHub. (ej:
uses: bencherdev/bencher@main
) -
Utiliza el subcomando
bencher run
de la CLI para ejecutar tus benchmarks de la rama del pull request. Ver el subcomandobencher run
de la CLI para una visión completa. (ej:bencher run
) -
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
) -
Establecer la opción
--token
al secreto del RepositorioBENCHER_API_TOKEN
. Ver la documentación de--token
para más detalles. (ej:--token '${{ secrets.BENCHER_API_TOKEN }}'
) -
Establecer la opción
--branch
al nombre de la rama PR usando el contextogithub
de GitHub Actions. Ver selección de rama para una visión completa. (ej:--branch '${{ github.head_ref }}'
) -
Establecer la opción
--branch-start-point
al punto de inicio de la rama base del PR usando el contextogithub
de GitHub Actions. Ver selección de rama para una visión completa. (ej:--branch-start-point '${{ github.base_ref }}'
) -
Establecer la opción
--branch-start-point-hash
al hash del punto de inicio de la rama base del PR usando el eventopull_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 }}'
) -
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
) -
Establecer la opción
--testbed
al nombre del Testbed. Esto debería coincidir con la máquina seleccionada enruns-on
. Ver la documentación de--testbed
para más detalles. (ej:--testbed ubuntu-latest
) -
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
) -
Establecer el flag
--err
para fallar el comando si se genera una Alerta. Ver Umbral y Alertas para una visión completa. (ej:--err
) -
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 entornoGITHUB_TOKEN
de GitHub Actions. Ver la documentación de--github-actions
para más detalles. (ej:--github-actions '${{ secrets.GITHUB_TOKEN }}'
) -
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.
-
Crea un primer 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ó 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 depull_request
de GitHub Actions para una visión completa. (ej:on: pull_request: types: [opened, reopened, edited, synchronize]
) -
Crea un
job
de GitHub Actions. (ej:jobs: benchmark_fork_pr_branch
) -
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
) -
Haz checkout del código fuente de la rama del fork PR. (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 del benchmark 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 primer 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
) - 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'
) - 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
) - Configura los nombres de los archivos de resultados del benchmark y del 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 del benchmark 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 el CLI de Bencher usando la acción de GitHub.
(ej:
uses: bencherdev/bencher@main
) - Usa el subcomando del CLI
bencher run
para seguir los benchmarks de tu rama de fork pull. Consulta el subcomandobencher run
del CLI para una visión completa. (ej:bencher run
) - 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
) - Configura la opción
--token
con el secreto del RepositorioBENCHER_API_TOKEN
. Consulta la documentación de la opción--token
para más detalles. (ej:--token '${{ secrets.BENCHER_API_TOKEN }}'
) - Configura la opción
--branch
con el número formateado del fork PR usando el eventopull_request
de GitHub Actions. Consulta la selección de ramas para una visión completa. (ej:--branch '${{ env.PR_HEAD }}'
) - Configura la opción
--branch-start-point
con el punto de inicio de la rama base del fork PR usando el eventopull_request
de GitHub Actions. Consulta la selección de ramas para una visión completa. (ej:--branch-start-point '${{ env.PR_BASE }}'
) - Configura la opción
--branch-start-point-hash
con el hash del punto de inicio de la rama base del fork PR usando el eventopull_request
de GitHub Actions. Consulta la selección de ramas para una visión completa. (ej:--branch-start-point-hash '${{ env.PR_BASE_SHA }}'
) - 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
) - Configura la opción
--testbed
con el nombre del Testbed. Esto probablemente debería coincidir con la máquina seleccionada enruns-on
. Consulta la documentación de la opción--tested
para más detalles. (ej:--testbed ubuntu-latest
) - 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
) - Configura el flag
--err
para fallar el comando si se genera una Alerta. Consulta Threshold & Alerts para una visión completa. (ej:--err
) - 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 entornoGITHUB_TOKEN
de GitHub Actions. Consulta la documentación de la opción--github-actions
para más detalles. (ej:--github-actions '${{ secrets.GITHUB_TOKEN }}'
) - 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 }}'
) - 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
.
-
Crea un archivo de
workflow
de GitHub Actions. (ej:.github/workflows/pr_target_benchmarks.yml
) -
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 sobrepull_request
para una visión completa. (ej:on: pull_request: types: [opened, reopened, edited, synchronize]
) -
Crea un primer
job
de GitHub Actions para verificar si el flujo de trabajo requiere revisión. (ej:jobs: fork_pr_requires_review
) -
Configura el
environment
ainternal
si y solo si el pull request es del mismo repositorio. De lo contrario, configura elenvironment
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
job
de GitHub Actions para ejecutar tus benchmarks. (ej:benchmark_fork_pr_branch
) -
Haz que el job
benchmark_fork_pr_branch
necesite el jobfork_pr_requires_review
para ejecutarse. ⚠️ ¡NO ELIMINES ESTA LÍNEA! Consulta la documentación de GitHub Actions sobreneeds
para una visión completa. (ej:needs: fork_pr_requires_review
) -
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
) -
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
)
- Especifica el repositorio del PR del fork (ej:
-
Instala la CLI de Bencher usando la Acción de GitHub. (ej:
uses: bencherdev/bencher@main
) -
Usa el subcomando de CLI
bencher run
para ejecutar tus benchmarks en la rama del pull request del fork. Consulta el subcomandobencher run
de CLI para una visión completa. (ej:bencher run
) -
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
) -
Configura la opción
--token
con el secreto del repositorioBENCHER_API_TOKEN
. Consulta los documentos de--token
para más detalles. (ej:--token '${{ secrets.BENCHER_API_TOKEN }}'
) -
Configura la opción
--branch
con el número de PR del fork formateado usando el eventopull_request
de GitHub Actions. Consulta la selección de rama para una visión completa. (ej:--branch '${{ github.event.number }}/merge'
) -
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 Actionsgithub
. Consulta la selección de rama para una visión completa. (ej:--branch-start-point '${{ github.base_ref }}'
) -
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 eventopull_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 }}'
) -
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
) -
Configura la opción
--testbed
con el nombre del Testbed. Esto debería coincidir probablemente con la máquina seleccionada enruns-on
. Consulta los documentos de--testbed
para más detalles. (ej:--testbed ubuntu-latest
) -
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
) -
Configura el flag
--err
para que falle el comando si se genera una Alerta. Consulta Threshold & Alerts para una visión completa. (ej:--err
) -
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 entornoGITHUB_TOKEN
de GitHub Actions. Consulta los documentos de--github-actions
para más detalles. (ej:--github-actions '${{ secrets.GITHUB_TOKEN }}'
) -
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! 🎉