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.

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

Rama Base

Una piedra angular del Benchmarking Continuo Estad铆stico es tener una l铆nea de base hist贸rica para tu rama base. Esta l铆nea de base hist贸rica puede ser utilizada para detectar regresiones de rendimiento en las Pull Requests.

on:
push:
branches: main
jobs:
benchmark_base_branch:
name: Continuous Benchmarking with Bencher
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: bencherdev/bencher@main
- name: Track base branch benchmarks with Bencher
run: |
bencher run \
--project save-walter-white-1234abcd \
--token '${{ secrets.BENCHER_API_TOKEN }}' \
--branch main \
--testbed ubuntu-latest \
--adapter json \
--err \
bencher mock
  1. Crea un archivo de flujo de trabajo de GitHub Actions. (Ej: .github/workflows/base_benchmarks.yml)
  2. Ejecutar en eventos de push a la rama main. Consulta la documentaci贸n de on de GitHub Actions y documentaci贸n de push de GitHub Actions para una visi贸n completa. (Ej: on: push: branches: main)
  3. Crea un trabajo de GitHub Actions. (Ej: jobs: benchmark_base_branch)
  4. Establece el tipo de m谩quina en la que se ejecutar谩 el trabajo. Consulta la documentaci贸n de runs-on de GitHub Actions para una visi贸n completa. (Ej: runs-on: ubuntu-latest)
  5. Haz checkout del c贸digo fuente de tu rama base. (Ej: uses: actions/checkout@v4)
  6. Instala el CLI Bencher usando la GitHub Action. (Ej: uses: bencherdev/bencher@main)
  7. Utiliza el subcomando CLI bencher run para ejecutar tus benchmarks de la rama main. Consulta el subcomando CLI bencher run para una visi贸n completa. (Ej: bencher run)
  8. Establece la opci贸n --project al slug del Proyecto. Consulta los docs de --project para m谩s detalles. (Ej: --project save-walter-white-1234abcd)
  9. Establece la opci贸n --token al secreto Repository BENCHER_API_TOKEN. Consulta los docs de --token para m谩s detalles. (Ej: --token '${{ secrets.BENCHER_API_TOKEN }}')
  10. Establece la opci贸n --branch al nombre de la Rama. Consulta selecci贸n de rama para una visi贸n completa. (Ej: --branch main)
  11. Establece la opci贸n --testbed al nombre de la Testbed. Probablemente deber铆a coincidir con la m谩quina seleccionada en runs-on. Consulta los docs de --testbed para m谩s detalles. (Ej: --testbed ubuntu-latest)
  12. Establece la opci贸n --adapter al adaptador de arn茅s de benchmarks deseado. Consulta adaptadores de arn茅s de benchmarks para una visi贸n completa. (Ej: --adapter json)
  13. Establece la bandera --err para fallar el comando si se genera una Alerta. Consulta Umbrales y Alertas para una visi贸n completa. (Ej: --err)
  14. Especifica los argumentos del comando de benchmark. Consulta comando de benchmark para una visi贸n completa. (Ej: bencher mock)

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, June 10, 2024 at 7:17:00 PM UTC