# Ejecutar pruebas con GitHub Actions > Lanza una ejecución automatizada en GitHub Actions desde Probara, prepara el workflow y sus secretos, y sigue el build desde la ejecución. Desde la página de ejecuciones de un proyecto puedes iniciar tu workflow de pruebas en **GitHub Actions**. Probara crea la ejecución, inicia el workflow en la rama que elijas y muestra el build en la ejecución, con su enlace, su estado, el inicio, el fin y la duración. Los jobs de prueba del workflow envían sus resultados a esa misma ejecución a través de los reporters de Probara, y un job final la cierra. Para ello hace falta la [integración con GitHub](https://docs.probara.net/es/guides/integrations/github/) instalada en el repositorio y un workflow preparado una sola vez, como se explica a continuación. ## Antes de empezar | Necesitas | Por qué | | ------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | La GitHub App de Probara instalada con acceso al repositorio | Probara lista los workflows y las ramas, inicia el workflow y recibe su estado a través de la aplicación. | | Un reporter de Probara en tus pruebas | Es quien envía los resultados. Consulta [Integraciones de CI](https://docs.probara.net/es/developers/ci-integrations/) para Playwright, Jest, Cypress, Vitest, Cucumber o JUnit XML. | | Un token de aplicación de ese reporter | El workflow se autentica con él. | | Permiso para ejecutar pruebas (miembros, administradores y propietarios) | Lanzar crea una ejecución. | ## 1. Añade el token y el proyecto al repositorio 1. En Probara, abre **Workspace › Integraciones**, selecciona la tarjeta de tu reporter (por ejemplo **Playwright**) y crea un token de aplicación en su pestaña **Tokens de acceso**. Cópialo: Probara solo lo muestra una vez. 2. En GitHub, abre **Settings › Secrets and variables › Actions** del repositorio. 3. En la pestaña **Secrets**, selecciona **New repository secret**. Llámalo `PROBARA_API_TOKEN` y pega el token. 4. En la pestaña **Variables**, selecciona **New repository variable**. Llámala `PROBARA_PROJECT` e introduce el ID del proyecto, por ejemplo `SHOP`. No subas nunca el token al repositorio. ## 2. Prepara el workflow Un workflow que Probara puede lanzar cumple tres reglas: | Regla | Por qué | | ------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------ | | Tiene un disparador `workflow_dispatch` con un input llamado `probara_run_id` | Probara envía en él el ULID de la ejecución. GitHub se niega a iniciar un workflow con un input que no declara. | | Su `run-name` contiene ese ULID, por ejemplo `Probara ` | Probara reconoce así la ejecución del workflow y actualiza el build en la ejecución. Sin él, el build se queda en **Enviado**. | | Cada job que envía resultados o cierra la ejecución define `PROBARA_RUN_ULID` con el input | Así los reporters envían sus resultados a esa ejecución y la dejan abierta para los demás jobs. | Este workflow ejecuta Playwright en cuatro shards en paralelo cuando Probara lo lanza, y en los `push` a `main` y en los `pull_request`. Su job final cierra la ejecución cuando terminan todos los shards. Sustituye los pasos de prueba por los tuyos: ```yaml name: Probara E2E run-name: ${{ inputs.probara_run_id && format('Probara {0}', inputs.probara_run_id) || github.workflow }} on: push: branches: [main] pull_request: workflow_dispatch: inputs: probara_run_id: description: Probara run ULID (set by Probara when it launches this workflow) required: false type: string env: PROBARA_API_TOKEN: ${{ secrets.PROBARA_API_TOKEN }} # Fork pull requests get no secrets: reporting stays off there. PROBARA_ENABLED: ${{ secrets.PROBARA_API_TOKEN != '' }} PROBARA_PROJECT: ${{ vars.PROBARA_PROJECT }} # Empty unless Probara launched the workflow: the reporters read an empty ULID as unset. PROBARA_RUN_ULID: ${{ inputs.probara_run_id }} jobs: test: runs-on: ubuntu-latest strategy: fail-fast: false matrix: shard: [1, 2, 3, 4] steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 with: node-version: 22 cache: npm - run: npm ci - run: npx playwright install --with-deps # The Probara reporter in playwright.config reads the PROBARA_ variables. - run: npx playwright test --shard=${{ matrix.shard }}/${{ strategy.job-total }} env: # Each shard leaves the run open; the final job closes it. PROBARA_CLOSE_RUN: false close-run: needs: test if: always() runs-on: ubuntu-latest steps: - uses: actions/setup-node@v4 with: node-version: 22 - run: npx --yes @probara/cli@0.6 run close ``` - **Los shards comparten una ejecución.** Si lo lanza Probara, cada shard envía sus resultados a la ejecución que creó Probara. Si no, los shards de una misma ejecución del workflow en GitHub comparten una ejecución propia: el primer shard que envía resultados la crea. - **El job final cierra la ejecución.** `if: always()` la cierra aunque fallen pruebas. Sin ese job, la ejecución sigue abierta cuando termina el workflow; puedes cerrarla igualmente desde Probara. - **¿Un solo job?** Añade el paso `run close` al final de ese job, con `if: always()`. En `push` y `pull_request` no se crea antes ninguna ejecución. Volver a ejecutar el workflow en GitHub es un intento nuevo, así que sus resultados van a una ejecución propia. ## 3. Lanza una ejecución 1. Abre **Ejecuciones** del proyecto y selecciona **Ejecutar en GitHub Actions**. El botón aparece cuando hay una cuenta de GitHub conectada y tu plan incluye integraciones. 2. Elige el **Repositorio**. La lista sigue los [repositorios del proyecto](https://docs.probara.net/es/guides/integrations/github/#elegir-los-repositorios-de-un-proyecto). 3. Elige la **Rama** y el **Workflow**. Solo aparecen los workflows activos. Para usar una rama que no aparece en la lista, escribe su nombre completo en la búsqueda de ramas y elige **Usar «nombre»**. 4. Si quieres, escribe un **Nombre de la ejecución (opcional)**. Por defecto es el workflow y la rama. 5. Selecciona **Iniciar ejecución**. Probara crea la ejecución, inicia el workflow una sola vez y abre la ejecución. Si GitHub se niega a iniciar el workflow, Probara muestra el motivo y no conserva ninguna ejecución. Si GitHub no responde, Probara conserva la ejecución e indica: «GitHub no confirmó el inicio. Si el workflow se ejecuta, su build aparece en la ejecución.» ## Seguir el build La cabecera de la ejecución muestra una tarjeta **GitHub Actions** mientras el workflow se ejecuta: - el estado: **Iniciando**, **Enviado**, **En cola**, **En curso** y, al terminar, el desenlace, como **Exitoso**, **Fallido** o **Cancelado**; - **Abrir en GitHub**, el enlace a la ejecución del workflow; - **Inicio**, **Fin** y **Duración**, que avanza mientras el workflow se ejecuta; - el intento, cuando no es el primero. La tarjeta sigue al workflow, pero nunca cierra la ejecución. Los resultados aparecen en la ejecución a medida que los envían los reporters. El enlace público de una ejecución nunca muestra el build. En **Origen de CI**, la ejecución también registra el **Repositorio**, la **Rama** y el **Workflow** con los que se lanzó. ## Volver a ejecutar un workflow lanzado GitHub vuelve a ejecutar un workflow con los mismos inputs, así que una nueva ejecución vuelve a nombrar la ejecución lanzada. Probara da a cada nuevo intento una ejecución propia, con el nombre de la ejecución lanzada y su intento, como "Nightly E2E · attempt 2", y la cierra cuando el intento termina en GitHub. La ejecución lanzada conserva los resultados y el build del primer intento. Para volver a probar en una ejecución nueva iniciada desde Probara, lanza el workflow de nuevo. ## Comentarios en pull requests Cuando se cierra o se aborta una ejecución que registra su pull request de GitHub Actions, Probara puede comentar sus resultados en ese pull request, de forma predeterminada solo cuando fallan pruebas. Cada comentario es nuevo y oculta el anterior (consulta [Comentarios en pull requests](https://docs.probara.net/es/guides/integrations/github/#comentarios-en-pull-requests)). Una ejecución lanzada parte de una rama, así que no registra ningún pull request. En un workflow de `pull_request`, los reporters y la CLI leen el número del pull request del evento de GitHub, así que la ejecución en la que informan sus jobs lo registra. Los informes enviados a la [API de informes](https://docs.probara.net/es/developers/api-reference/#reportes-de-ci) también pueden incluir el repositorio y el número del pull request en `run.source`. ## Solución de problemas | Mensaje o situación | Qué hacer | | --------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | | «Este workflow no se puede iniciar desde Probara: está desactivado o no tiene el disparador workflow_dispatch.» | Activa el workflow en GitHub o añádele el disparador `workflow_dispatch`. | | «Este workflow aún no está preparado para Probara: debe declarar el input probara_run_id …» | Declara el input `probara_run_id` en `workflow_dispatch`, como en [Prepara el workflow](#2-prepara-el-workflow). | | «GitHub rechazó iniciar el workflow: …» con un input inesperado | Declara ese input en `workflow_dispatch` o deja de enviarlo. | | «El repositorio no tiene una rama con ese nombre.» | La rama se eliminó o se renombró. Vuelve a elegirla. | | «El repositorio no tiene ese workflow.» | El archivo del workflow se eliminó o se renombró. Vuelve a elegirlo. | | «Ningún repositorio de GitHub está disponible para este proyecto.» | Da acceso a la GitHub App al repositorio, o añádelo en **Configuración › GitHub** del proyecto. | | «Este repositorio no tiene workflows activos.» | Añade un workflow al repositorio o actívalo en GitHub. | | El build se queda en **Enviado** | El `run-name` del workflow no contiene el ULID de la ejecución. Usa la línea `run-name` de arriba. | | La ejecución sigue abierta después de terminar el workflow | Añade el job final con `run close`, o cierra la ejecución en Probara. | | Un job muestra «… was already closed: this job reported after the job that closes it» (409 `ci_run_closed`) | Incluye cada job que envía resultados en `needs` del job final. Define `PROBARA_CLOSE_RUN: false` en los jobs en paralelo. | | Una ejecución lanzada no tiene resultados | Comprueba que cada job de prueba define `PROBARA_RUN_ULID` y que el secreto y la variable se llaman exactamente `PROBARA_API_TOKEN` y `PROBARA_PROJECT`. | ## Automatizarlo Los scripts y los asistentes de IA pueden lanzar ejecuciones de la misma forma con un [token de API](https://docs.probara.net/es/developers/authentication/) o con [Probara MCP](https://docs.probara.net/es/developers/mcp/): los endpoints están en la página [API de GitHub](https://docs.probara.net/es/developers/api/github/#lanzar-un-workflow), y las herramientas MCP son `list_github_workflows`, `list_github_branches` y `launch_github_workflow`.