Ejecutar pruebas con GitHub Actions

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 instalada en el repositorio y un workflow preparado una sola vez, como se explica a continuación.

Antes de empezar

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:

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:

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.
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).

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 también pueden incluir el repositorio y el número del pull request en run.source.

Solución de problemas

Automatizarlo

Los scripts y los asistentes de IA pueden lanzar ejecuciones de la misma forma con un token de API o con Probara MCP: los endpoints están en la página API de GitHub, y las herramientas MCP son list_github_workflows, list_github_branches y launch_github_workflow.