Cómo usar Bencher en GitHub Actions
Depending on your use case, you can set up Continuous Benchmarking in GitHub Actions for your:
Make sure you have created an API token
and set it as a Repository secret named BENCHER_API_TOKEN before continuing on!
Navigate to Your Repo -> Settings -> Secrets and variables -> Actions -> New repository secret.
Name the secret BENCHER_API_TOKEN and set the secret value to your API token.
In GitHub Actions,
secrets are not passed to the runner when a workflow is triggered from a forked repository.
Therefore, you will need to use a branch from the same repository
when adding any of the workflows below to your repository with a pull request.
If you try to add Bencher with a pull request from a fork,
then the BENCHER_API_TOKEN secret will not be available.
${{ secrets.BENCHER_API_TOKEN }} will be an empty string.
Rama Base
Una piedra angular de Benchmarking Continuo Estadístico es tener una línea base histórica para tu rama base. Esta línea base histórica puede luego usarse para detectar regresiones de rendimiento en las Pull Requests.
on: push: branches: main
jobs: benchmark_base_branch: name: Continuous Benchmarking with Bencher permissions: checks: write runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: bencherdev/bencher@main - name: Track base branch benchmarks with Bencher run: | bencher run \ --project project-abc4567-wxyz123456789 \ --token '${{ secrets.BENCHER_API_TOKEN }}' \ --branch main \ --testbed ubuntu-latest \ --threshold-measure latency \ --threshold-test t_test \ --threshold-max-sample-size 64 \ --threshold-upper-boundary 0.99 \ --thresholds-reset \ --err \ --adapter json \ --github-actions '${{ secrets.GITHUB_TOKEN }}' \ bencher mock- Crear un archivo de
workflowpara GitHub Actions. (ej:.github/workflows/base_benchmarks.yml) - Ejecutar en eventos de
pusha la ramamain. Consulta la documentaciónonde GitHub Actions y la documentación depushde GitHub Actions para una visión completa. (ej:on: push: branches: main) - Crear un
jobde GitHub Actions. (ej:jobs: benchmark_base_branch) - Establece los permisos para el
GITHUB_TOKENawriteparachecks. (ej:permissions: checks: write) - Establecer el tipo de máquina en la que se ejecutará el job.
Consulta la documentación
runs-onde GitHub Actions para una visión completa. (ej:runs-on: ubuntu-latest) - Revisa tu código fuente de la rama base.
(ej:
uses: actions/checkout@v4) - Instala la CLI de Bencher usando la Acción de GitHub.
(ej:
uses: bencherdev/bencher@main) - Usa el subcomando
bencher runde la CLI para ejecutar tus benchmarks de la ramamain. Consulta el subcomandobencher runde la CLI para una visión completa. (ej:bencher run) - Establece la opción
--projectal slug del Proyecto. Consulta la documentación de--projectpara más detalles. (ej:--project project-abc4567-wxyz123456789) - Establece la opción
--tokenal secreto de RepositorioBENCHER_API_TOKEN. Consulta la documentación de--tokenpara más detalles. (ej:--token '${{ secrets.BENCHER_API_TOKEN }}') - Establece la opción
--branchal nombre de la Rama base. Consulta la documentación de--branchpara una visión completa. (ej:--branch main) - Establece la opción
--testbedal nombre del Testbed. Esto debería probablemente coincidir con la máquina seleccionada enruns-on. Consulta la documentación de--testbedpara más detalles. (ej:--testbed ubuntu-latest) - Establece el Umbral para la Rama
main, Testbedubuntu-latesty la Medidalatency:- Establece la opción
--threshold-measurea la Medida incorporadalatencyque generabencher mock. Consulta la documentación de--threshold-measurepara más detalles. (ej:--threshold-measure latency) - Establece la opción
--threshold-testa una prueba t de Student (t_test). Consulta la documentación de--threshold-testpara una visión completa. (ej:--threshold-test t_test) - Establece la opción
--threshold-max-sample-sizeal tamaño máximo de muestra de64. Consulta la documentación de--threshold-max-sample-sizepara más detalles. (ej:--threshold-max-sample-size 64) - Establece la opción
--threshold-upper-boundaryal Límite Superior de0.99. Consulta la documentación de--threshold-upper-boundarypara más detalles. (ej:--threshold-upper-boundary 0.99) - Establece la bandera
--thresholds-resetpara que solo el Umbral especificado esté activo. Consulta la documentación de--thresholds-resetpara una visión completa. (ej:--thresholds-reset)
- Establece la opción
- Establece la bandera
--errpara que el comando falle si se genera una Alerta. Consulta la documentación de--errpara una visión completa. (ej:--err) - Establece la opción
--adapteral Formato JSON de Métricas de Bencher (json) que generabencher mock. Consulta adaptadores de harness de benchmark para una visión completa. (ej:--adapter json) - Establece la opción
--github-actionsal token de autenticación de la API de GitHub para publicar resultados como un comentario de Checks de GitHub usando la variable de entornoGITHUB_TOKENde GitHub Actions. Consulta la documentación de--github-actionspara más detalles. (ej:--github-actions '${{ secrets.GITHUB_TOKEN }}') - Especifica los argumentos del comando del benchmark.
Consulta comando de benchmark para una visión completa.
(ej:
bencher mock)
Pull Requests
Para detectar regresiones de rendimiento en las Pull Requests, necesitarás ejecutar tus benchmarks en las PRs.
Si solo esperas tener PRs desde ramas dentro del mismo repositorio,
entonces simplemente puedes crear otro flujo de trabajo para ejecutar on eventos de pull_request desde el mismo repositorio.
⚠️ ¡Esta solución solo funciona si todas las PRs son del mismo repositorio! Consulta 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 project-abc4567-wxyz123456789 \ --token '${{ secrets.BENCHER_API_TOKEN }}' \ --branch "$GITHUB_HEAD_REF" \ --start-point "$GITHUB_BASE_REF" \ --start-point-hash '${{ github.event.pull_request.base.sha }}' \ --start-point-clone-thresholds \ --start-point-reset \ --testbed ubuntu-latest \ --err \ --adapter json \ --github-actions '${{ secrets.GITHUB_TOKEN }}' \ bencher mock-
Crea un archivo de
workflowde GitHub Actions. (ej:.github/workflows/pr_benchmarks.yml) -
Ejecuta en eventos de
pull_request:opened- Se creó una pull request.reopened- Se reabrió una pull request previamente cerrada.edited- Se editó el título o el cuerpo de una pull request, o se cambió la rama base de una pull request.synchronize- Se actualizó la rama de encabezado de una pull request. Por ejemplo, se actualizó la rama de encabezado desde la rama base o se hicieron nuevos commits a la rama de encabezado.
Revisa la documentación de GitHub Actions
ony la documentación de GitHub Actionspull_requestpara una visión completa. (ej:on: pull_request: types: [opened, reopened, edited, synchronize]) -
Crea un
jobde GitHub Actions. (ej:jobs: benchmark_pr_branch) -
Ejecuta en eventos de
pull_requestsi y solo si la pull request es del mismo repositorio. ⚠️ ¡NO ELIMINES ESTA LÍNEA! Para manejar PRs de Forks, consulta Pull Requests desde 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_TOKENawriteparapull-requests. Dependiendo de tu configuración de 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. 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-onpara una visión completa. (ej:runs-on: ubuntu-latest) -
Clona el código fuente de la rama PR. (ej:
uses: actions/checkout@v4) -
Instala el Bencher CLI usando la GitHub Action. (ej:
uses: bencherdev/bencher@main) -
Usa la subcomando CLI
bencher runpara ejecutar tus benchmarks de la rama de la pull request. Consulta la subcomando CLIbencher runpara una visión completa. (ej:bencher run) -
Establece la opción
--projectal slug del Proyecto. Consulta los documentos de--projectpara más detalles. (ej:--project project-abc4567-wxyz123456789) -
Establece la opción
--tokenal secreto RepositoryBENCHER_API_TOKEN. Consulta los documentos de--tokenpara más detalles. (ej:--token '${{ secrets.BENCHER_API_TOKEN }}') -
Establece la opción
--branchal nombre de la rama PR usando la variable de entorno predeterminadaGITHUB_HEAD_REFde GitHub Actions. Consulta los documentos de--branchpara una visión completa. (ej:--branch "$GITHUB_HEAD_REF") -
Establece el Punto de Inicio para la Rama PR:
- Establece la opción
--start-pointal punto de inicio de la Rama PR usando la variable de entorno predeterminadaGITHUB_BASE_REFde GitHub Actions. Consulta los documentos de--start-pointpara una visión completa. (ej:--start-point "$GITHUB_BASE_REF") - Establece la opción
--start-point-hashal hashgitdel punto de inicio de la Rama PR usando el eventopull_requestde GitHub Actions. Consulta los documentos de--start-point-hashpara una visión completa. (ej:--start-point-hash '${{ github.event.pull_request.base.sha }}') - Establece la bandera
--start-point-clone-thresholdspara clonar los Umbrales desde el punto de inicio. Consulta los documentos de--start-point-clone-thresholdspara una visión completa. (ej:--start-point-clone-thresholds) - Establece la bandera
--start-point-resetpara siempre restablecer la Rama PR al punto de inicio. Esto evitará la deriva de datos de benchmark. Consulta los documentos de--start-point-resetpara una visión completa. (ej:--start-point-reset)
- Establece la opción
-
Establece la opción
--testbedal nombre del Testbed. Esto debería coincidir con la máquina seleccionada enruns-on. Consulta los documentos de--testedpara más detalles. (ej:--testbed ubuntu-latest) -
Establece la bandera
--errpara fallar el comando si se genera una Alerta. Consulta los documentos de--errpara una visión completa. (ej:--err) -
Establece la opción
--adapteral Formato de Métrica Bencher JSON (json) que es generado porbencher mock. Consulta adaptadores de harness de benchmark para una visión completa. (ej:--adapter json) -
Establece la opción
--github-actionsal token de autenticación de la API de GitHub para publicar resultados como un comentario en la Pull Request usando la variable de entornoGITHUB_TOKENde GitHub Actions. Consulta los documentos de--github-actionspara más detalles. (ej:--github-actions '${{ secrets.GITHUB_TOKEN }}') -
Especifica los argumentos del comando de benchmark. Consulta comando de benchmark para una visión completa. (ej:
bencher mock)
Para limpiar la rama de PR después de que su PR esté cerrado, puedes crear un flujo de trabajo separado para ejecutarse on eventos de pull_request con el tipo closed. Este flujo de trabajo archivará la rama del PR usando el comando bencher archive.
on: pull_request: types: [closed]
jobs: archive_pr_branch: name: Archive closed PR branch with Bencher # DO NOT REMOVE: For handling Fork PRs see Pull Requests from Forks if: github.event_name == 'pull_request' && github.event.pull_request.head.repo.full_name == github.repository runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: bencherdev/bencher@main - name: Archive closed PR branch with Bencher run: | bencher archive \ --project project-abc4567-wxyz123456789 \ --token '${{ secrets.BENCHER_API_TOKEN }}' \ --branch "$GITHUB_HEAD_REF"-
Crea un archivo de
workflowde GitHub Actions. (ej:.github/workflows/pr_benchmarks_closed.yml) -
Ejecutar en eventos
pull_request:closed- Una solicitud de extracción fue cerrada.
Consulta la documentación de GitHub Actions
ony la documentación de GitHub Actionspull_requestpara una visión completa. (ej:on: pull_request: types: [closed]) -
Crea un
jobde GitHub Actions. (ej:jobs: archive_pr_branch) -
Ejecutar en eventos
pull_requestsi 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 Forks a continuación. (ej:if: github.event_name == 'pull_request' && github.event.pull_request.head.repo.full_name == github.repository) -
Establecer el tipo de máquina en la que el trabajo se ejecutará. Consulta la documentación de GitHub Actions
runs-onpara una visión completa. (ej:runs-on: ubuntu-latest) -
Checkout del código fuente de la rama PR. (ej:
uses: actions/checkout@v4) -
Instala el CLI de Bencher usando la Acción de GitHub. (ej:
uses: bencherdev/bencher@main) -
Utiliza el subcomando
bencher archivedel CLI para archivar la rama PR. (ej:bencher archive) -
Configura la opción
--projectal identificador del Proyecto. Consulta la documentación de--projectpara más detalles. (ej:--project project-abc4567-wxyz123456789) -
Configura la opción
--tokenal secreto de RepositoryBENCHER_API_TOKEN. Consulta la documentación de--tokenpara más detalles. (ej:--token '${{ secrets.BENCHER_API_TOKEN }}') -
Configura la opción
--branchal nombre de la rama PR usando la variable de entorno predeterminadaGITHUB_HEAD_REFde GitHub Actions. (ej:--branch "$GITHUB_HEAD_REF")
Pull Requests desde Forks
Si planeas aceptar pull requests desde forks, como suele ser el caso en proyectos de código abierto público,
entonces tendrás que 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 desde forks.
Es decir, si un contribuyente externo abre un PR desde un fork, el ejemplo anterior no funcionará.
Consulta este artículo del GitHub Security Lab
y esta entrada de blog
sobre cómo prevenir solicitudes de pwn para obtener una visión completa.
Esta es la forma segura y recomendada de añadir Continuous Benchmarking a los pull requests desde 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 hay secretos como tu BENCHER_API_TOKEN y el GITHUB_TOKEN disponibles allí.
Entonces, 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 por defecto del repositorio,
donde los secretos como tu BENCHER_API_TOKEN y el GITHUB_TOKEN están disponibles.
El número de pull request, la rama principal y la rama base utilizada en el flujo de trabajo inicial pull_request
también deben pasarse explícitamente al flujo de trabajo workflow_run ya que no están disponibles allí.
Estos flujos de trabajo solo se ejecutarán si existen en la rama predeterminada.
Consulta usando datos del flujo de trabajo desencadenante para obtener una visión completa.
name: Run Benchmarks
on: pull_request: types: [opened, reopened, edited, synchronize]
jobs: benchmark_fork_pr_branch: name: Run Fork PR Benchmarks runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Mock Benchmarking run: | /bin/echo '{ "bencher::mock_0": { "latency": { "value": 1.0 } } }' > benchmark_results.json - name: Upload Benchmark Results uses: actions/upload-artifact@v4 with: name: benchmark_results.json path: ./benchmark_results.json - name: Upload GitHub Pull Request Event uses: actions/upload-artifact@v4 with: name: event.json path: ${{ github.event_path }}-
Crea un primer archivo de
workflowde GitHub Actions. (ej:.github/workflows/fork_pr_benchmarks_run.yml) -
Nombra este flujo de trabajo para que pueda ser referenciado por el segundo flujo de trabajo. (ej:
name: Run Benchmarks) -
Ejecuta en eventos de
pull_request:opened- Se creó una solicitud de extracción.reopened- Se reabrió una solicitud de extracción previamente cerrada.edited- Se editó el título o cuerpo de una solicitud de extracción, o se cambió la rama base de una solicitud de extracción.synchronize- Se actualizó la rama de cabecera de una solicitud de extracción. Por ejemplo, se actualizó la rama de cabecera desde la rama base o se empujaron nuevos commits a la rama de cabecera.
Consulta la documentación de
onde GitHub Actions y la documentación depull_requestde GitHub Actions para una vista completa. (ej:on: pull_request: types: [opened, reopened, edited, synchronize]) -
Crea un
jobde GitHub Actions. (ej:jobs: benchmark_fork_pr_branch) -
Establece el tipo de máquina en el que se ejecutará el trabajo. Consulta la documentación de
runs-onde GitHub Actions para una vista completa. (ej:runs-on: ubuntu-latest) -
Verifica el código fuente de la rama PR del fork. (ej:
uses: actions/checkout@v4) -
Ejecuta tus pruebas de rendimiento y guarda los resultados en un archivo. (ej:
/bin/echo '{ ... }' > benchmark_results.json) -
Sube el archivo de resultados de pruebas de rendimiento como artefacto. (ej:
uses: actions/upload-artifact@v4) -
Sube el objeto del evento
pull_requestcomo artefacto. (ej:uses: actions/upload-artifact@v4)
name: Track Benchmarks with Bencher
on: workflow_run: workflows: [Run Benchmarks] types: [completed]
jobs: track_fork_pr_branch: if: github.event.workflow_run.conclusion == 'success' permissions: pull-requests: write runs-on: ubuntu-latest env: BENCHMARK_RESULTS: benchmark_results.json PR_EVENT: event.json steps: - name: Download Benchmark Results uses: dawidd6/action-download-artifact@v6 with: name: ${{ env.BENCHMARK_RESULTS }} run_id: ${{ github.event.workflow_run.id }} - name: Download PR Event uses: dawidd6/action-download-artifact@v6 with: name: ${{ env.PR_EVENT }} run_id: ${{ github.event.workflow_run.id }} - name: Export PR Event Data uses: actions/github-script@v6 with: script: | let fs = require('fs'); let prEvent = JSON.parse(fs.readFileSync(process.env.PR_EVENT, {encoding: 'utf8'})); core.exportVariable("PR_HEAD", prEvent.pull_request.head.ref); core.exportVariable("PR_HEAD_SHA", prEvent.pull_request.head.sha); 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 project-abc4567-wxyz123456789 \ --token '${{ secrets.BENCHER_API_TOKEN }}' \ --branch "$PR_HEAD" \ --hash "$PR_HEAD_SHA" \ --start-point "$PR_BASE" \ --start-point-hash "$PR_BASE_SHA" \ --start-point-clone-thresholds \ --start-point-reset \ --testbed ubuntu-latest \ --err \ --adapter json \ --github-actions '${{ secrets.GITHUB_TOKEN }}' \ --ci-number "$PR_NUMBER" \ --file "$BENCHMARK_RESULTS"- Crea un primer archivo de
workflowde GitHub Actions. (ej:.github/workflows/fork_pr_benchmarks_track.yml) - Nombra este workflow como segundo workflow.
(ej:
name: Track Benchmarks with Bencher) - Encadena los dos workflows con
el evento
workflow_run. (ej:on: workflow_run: ...) - Crea un
jobde GitHub Actions. (ej:jobs: track_fork_pr_branch) - Ejecuta este job solo si la conclusión del workflow anterior fue un éxito usando
el evento
workflow_runde GitHub Actions. (ej:if: github.event.workflow_run.conclusion == 'success') - Establece los permisos para el
GITHUB_TOKENcomowriteparapull-requests. Dependiendo de la configuración de tu GitHub, esto puede no ser necesario. Pero para todas las organizaciones y repositorios personales creados después del 02 de febrero de 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 el job se ejecutará.
Consulta la documentación de
runs-onde GitHub Actions para una visión completa. (ej:runs-on: ubuntu-latest) - Establece los resultados de las pruebas y los nombres de los archivos de objetos de eventos
pull_requestcomo variables de entorno. (ej:env: ...) - Descarga los resultados de pruebas almacenados en caché y el evento
pull_requestusando la acción GitHubaction-download-artifact. (ej:uses: dawidd6/action-download-artifact@v6) - Exporta los datos necesarios desde el evento
pull_requestcomo variables de entorno intermedias. (ej:core.exportVariable(...)) - Instala el CLI de Bencher usando la acción de GitHub.
(ej:
uses: bencherdev/bencher@main) - Usa el subcomando CLI
bencher runpara llevar un seguimiento de los benchmarks de la rama de pull request del fork. Consulta el subcomando CLIbencher runpara una visión completa. (ej:bencher run) - Establece la opción
--projectal slug del Proyecto. Consulta los documentos de--projectpara más detalles. (ej:--project project-abc4567-wxyz123456789) - Establece la opción
--tokenal secreto del RepositorioBENCHER_API_TOKEN. Consulta los documentos de--tokenpara más detalles. (ej:--token '${{ secrets.BENCHER_API_TOKEN }}') - Establece la opción
--branchal nombre de la rama PR del fork usando una variable de entorno intermedia. Consulta los documentos de--branchpara una visión completa. (ej:--branch "$PR_HEAD") - Establece la opción
--hashal hashgitde la rama PR del fork usando una variable de entorno intermedia. Consulta los documentos de--hashpara una visión completa. (ej:--hash "$PR_HEAD_SHA") - Establece el Punto de Inicio para la Ramas PR del fork:
- Establece la opción
--start-pointal punto de inicio de la Ramas PR del fork usando una variable de entorno intermedia. Consulta los documentos de--start-pointpara una visión completa. (ej:--start-point "$PR_BASE") - Establece la opción
--start-point-hashal hashgitdel punto de inicio de la Ramas PR del fork usando una variable de entorno intermedia. Consulta los documentos de--start-point-hashpara una visión completa. (ej:--start-point-hash "$PR_BASE_SHA") - Establece el flag
--start-point-clone-thresholdspara clonar las Umbrales desde el punto de inicio. Consulta los documentos de--start-point-clone-thresholdspara una visión completa. (ej:--start-point-clone-thresholds) - Establece el flag
--start-point-resetpara siempre restablecer la Ramas PR del fork al punto de inicio. Esto evitará la deriva de datos de benchmark. Consulta los documentos de--start-point-resetpara una visión completa. (ej:--start-point-reset)
- Establece la opción
- Establece la opción
--testbedal nombre del Entorno de Pruebas. Es probable que esto coincida con la máquina seleccionada enruns-on. Consulta los documentos de--testedpara más detalles. (ej:--testbed ubuntu-latest) - Establece el flag
--errpara que el comando falle si se genera una Alerta. Consulta los documentos de--errpara una visión completa. (ej:--err) - Establece la opción
--adapteral Formato de Métrica Bencher JSON (json) que es generado porbencher mock. Consulta los adaptadores de harness de benchmark para una visión completa. (ej:--adapter json) - Establece la opción
--github-actionsal token de autenticación de la API de GitHub para publicar resultados como un comentario en la Pull Request usando la variable de entornoGITHUB_TOKENde GitHub Actions. Consulta los documentos de--github-actionspara más detalles. (ej:--github-actions '${{ secrets.GITHUB_TOKEN }}') - Establece la opción
--ci-numberal número de la pull request usando una variable de entorno intermedia. Consulta los documentos de--ci-numberpara más detalles. (ej:--ci-number "$PR_NUMBER") - Establece la opción
--filea la ruta del archivo de resultados de benchmark. Consulta comando de benchmark para una visión completa. (ej:--file "$BENCHMARK_RESULTS")
Para limpiar la rama del PR del fork después de que se cierre su PR,
puedes crear un flujo de trabajo separado para ejecutar en eventos on pull_request_target con el tipo closed.
Este flujo de trabajo archivará la rama del PR del fork utilizando el comando bencher archive.
on: pull_request_target: types: [closed]
jobs: archive_fork_pr_branch: name: Archive closed fork PR branch with Bencher runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: bencherdev/bencher@main - name: Archive closed fork PR branch with Bencher run: | bencher archive \ --project project-abc4567-wxyz123456789 \ --token '${{ secrets.BENCHER_API_TOKEN }}' \ --branch "$GITHUB_HEAD_REF"-
Crea un archivo de
workflowde GitHub Actions. (ej:.github/workflows/fork_pr_benchmarks_closed.yml) -
Ejecuta en eventos
pull_request_target:closed- Se cerró un pull request.
Consulta la documentación sobre
onde GitHub Actions y la documentación sobrepull_request_targetde GitHub Actions para una visión general completa. (ej:on: pull_request_target: types: [closed]) -
Crea un
jobde GitHub Actions. (ej:jobs: archive_pr_branch) -
Establece el tipo de máquina en que correrá el trabajo. Consulta la documentación sobre
runs-onde GitHub Actions para una visión general completa. (ej:runs-on: ubuntu-latest) -
Revisa el código fuente de la rama del PR. (ej:
uses: actions/checkout@v4) -
Instala el Bencher CLI usando la acción de GitHub. (ej:
uses: bencherdev/bencher@main) -
Usa el subcomando CLI
bencher archivepara archivar la rama del PR. (ej:bencher archive) -
Establece la opción
--projectcon el slug del Proyecto. Consulta los documentos de la opción--projectpara más detalles. (ej:--project project-abc4567-wxyz123456789) -
Establece la opción
--tokencon el secreto RepositorioBENCHER_API_TOKEN. Consulta los documentos de la opción--tokenpara más detalles. (ej:--token '${{ secrets.BENCHER_API_TOKEN }}') -
Establece la opción
--branchcon el nombre de la rama del PR usando la variable de entorno predeterminadaGITHUB_HEAD_REFde GitHub Actions. (ej:--branch "$GITHUB_HEAD_REF")
🐰 ¡Felicidades! ¡Has aprendido cómo usar Bencher en GitHub Actions! 🎉