# Configuración del reporter de Playwright > Cada opción de @probara/playwright-reporter con su variable PROBARA_*, su tipo y su valor por defecto, cómo se resuelve la precedencia y cómo se comporta en la red. Cada ajuste es una opción del reporter en `playwright.config`, y la mayoría tiene también una variable de entorno `PROBARA_*`. Deja el token en el entorno, el proyecto en la configuración (o en el entorno), y el resto donde mejor encaje en tu pipeline. ## Camino rápido 1. Crea un token de aplicación desde la tarjeta **Playwright** en **Workspace › Integraciones** ([primeros pasos](https://docs.probara.net/es/developers/ci-integrations/playwright/#1-crea-un-token-de-aplicación)) y guárdalo como un secreto de CI llamado `PROBARA_API_TOKEN`. 2. Define el ID del Proyecto: `projectId` en las opciones del reporter, o `PROBARA_PROJECT`. Es una letra mayúscula seguida de mayúsculas o dígitos (`SHOP`, `E2E`); cualquier otro valor desactiva el envío con un error. 3. Deja el resto con su valor por defecto. La ejecución toma el nombre del build de CI, y su rama, su commit y la URL del build salen del CI. ```ts // playwright.config.ts import { defineConfig } from '@playwright/test'; export default defineConfig({ reporter: [['list'], ['@probara/playwright-reporter', { projectId: 'SHOP' }]], }); ``` `apiToken` existe para el código que lee el token de su propio almacén de secretos. No escribas el token en `playwright.config`: el archivo se sube al repositorio. ## Fuentes y precedencia Gana la primera fuente que define un valor: | Orden | Fuente | Ejemplo | | ----- | --------------------------------- | ----------------------------------------------- | | 1 | Una opción en `playwright.config` | `{ run: { name: 'Release 2.4' } }` | | 2 | Una variable `PROBARA_*` | `PROBARA_RUN_NAME=Nightly` | | 3 | La detección del CI | `CI #42`, del workflow y el número de ejecución | | 4 | El valor por defecto | `Automated run 2026-09-29 14:05 UTC` | - Una opción con valor `undefined` nunca oculta su variable, y una variable vacía cuenta como no definida. Para que una variable pueda sustituir a una opción, omite la opción (o pasa `process.env.X ?? default`). - Los booleanos aceptan `true`, `1`, `yes`, `on` y `false`, `0`, `no`, `off`. Las listas van separadas por comas en las variables (`PROBARA_RUN_TAGS=nightly,smoke`), y los registros son pares `key=value` (`PROBARA_RUN_ULIDS=WEB=,API=`). - La detección del CI solo rellena el nombre de la ejecución y su origen (rama, commit, URL del build, y en GitHub Actions la ejecución del workflow que agrupa los jobs en paralelo): consulta [qué rellena cada CI](https://docs.probara.net/es/developers/ci-integrations/playwright/results-and-retries/#origen-de-la-ejecución). Puedes combinar opciones y variables. Esta configuración define el proyecto y las etiquetas, y el pipeline añade el entorno con `PROBARA_ENVIRONMENT=staging`: ```ts reporter: [ ['list'], ['@probara/playwright-reporter', { projectId: 'SHOP', run: { tags: ['e2e', 'nightly'] } }], ], ``` ## Opciones | Opción | Variable | Tipo | Por defecto | Qué hace | | ------------------------ | ------------------------------ | --------------------------------------- | ------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `enabled` | `PROBARA_ENABLED` | `boolean` | activado | `false` desactiva el envío: no se envía ni se registra nada | | `apiToken` | `PROBARA_API_TOKEN` | `string` | ninguno (obligatorio) | El token de aplicación. Déjalo en el entorno | | `projectId` | `PROBARA_PROJECT` | `string` | ninguno (obligatorio) | El ID del Proyecto (mayúsculas y dígitos), por ejemplo `SHOP` | | `baseUrl` | `PROBARA_BASE_URL` | `string` | `https://app.probara.net` | El host de Probara al que enviar ([URL base](#url-base)) | | `run.ulid` | `PROBARA_RUN_ULID` | `string` | ninguno: una ejecución nueva | Enviar a una ejecución existente ([shards](https://docs.probara.net/es/developers/ci-integrations/playwright/sharding/)) | | `run.name` | `PROBARA_RUN_NAME` | `string` | el nombre del build de CI, si no `Automated run ` | Nombre de una ejecución nueva | | `run.description` | `PROBARA_RUN_DESCRIPTION` | `string` | ninguno | Descripción de una ejecución nueva | | `run.environment` | `PROBARA_ENVIRONMENT` | `string` | ninguno | Entorno de una ejecución nueva por nombre, que se crea si no existe ([opciones de la ejecución](https://docs.probara.net/es/developers/ci-integrations/playwright/results-and-retries/#opciones-de-la-ejecución)) | | `run.environmentId` | `PROBARA_ENVIRONMENT_ID` | `string` | ninguno | Entorno de una ejecución nueva por ULID | | `run.milestone` | `PROBARA_MILESTONE` | `string` | ninguno | Hito de una ejecución nueva por ID visible (`M-3`) o nombre | | `run.milestoneId` | `PROBARA_MILESTONE_ID` | `string` | ninguno | Hito de una ejecución nueva por ULID | | `run.plan` | `PROBARA_PLAN` | `string` | ninguno | Plan de prueba de una ejecución nueva por ID visible (`PLAN-2`) o nombre: la ejecución empieza con sus casos | | `run.configurations` | `PROBARA_CONFIGURATIONS` | `{ group, name }[]` | ninguno | Configuraciones de una ejecución nueva por nombre (`Browser=Chrome,OS=Linux`), cada grupo una vez | | `run.configurationUlids` | `PROBARA_CONFIGURATION_ULIDS` | `string[]` | ninguno | Configuraciones de una ejecución nueva por ULID | | `run.tags` | `PROBARA_RUN_TAGS` | `string[]` | ninguno | Etiquetas de una ejecución nueva | | `run.ulids` | `PROBARA_RUN_ULIDS` | `Record` | ninguno | La ejecución que reutilizar en cada proyecto (`WEB=,API=`) ([varios proyectos](https://docs.probara.net/es/developers/ci-integrations/playwright/sharding/#varios-proyectos-de-probara)) | | `projects` | `PROBARA_PROJECTS` | `string[]` | ninguno | Otros proyectos a los que pueden ir los resultados (`WEB,API`) ([varios proyectos](https://docs.probara.net/es/developers/ci-integrations/playwright/sharding/#varios-proyectos-de-probara)) | | `source` | — | `false \| objeto (campos GitHub abajo)` | detectado del CI | `false` no envía origen; un objeto sustituye los campos detectados uno a uno | | `source.branch` | `PROBARA_BRANCH` | `string` | detectado del CI | Rama del origen de la ejecución | | `source.commit` | `PROBARA_COMMIT` | `string` | detectado del CI | Commit del origen de la ejecución | | `source.buildUrl` | `PROBARA_BUILD_URL` | `string` | detectado del CI | URL del build de CI del origen de la ejecución | | `createMissingCases` | `PROBARA_CREATE_MISSING_CASES` | `boolean` | `true` | Crear un caso para una prueba que no coincide con ninguno ([casos que faltan](https://docs.probara.net/es/developers/ci-integrations/playwright/linking/#casos-que-faltan)) | | `suiteUlid` | `PROBARA_SUITE_ULID` | `string` | la raíz del proyecto | Suite bajo la que se crean los casos | | `closeRun` | `PROBARA_CLOSE_RUN` | `boolean` | `true` para una ejecución nueva, `false` para una reutilizada | Cerrar la ejecución al final | | `closeRuns` | — | `Record` | ninguno | Cerrar la ejecución de cada proyecto (`{ SHOP: true, WEB: false }`) cuando `closeRun` no está definido | | `uploadAttachments` | `PROBARA_UPLOAD_ATTACHMENTS` | `boolean` | `true` | `false` no sube ningún archivo ([adjuntos](https://docs.probara.net/es/developers/ci-integrations/playwright/steps-and-attachments/#adjuntos)) | | `captureOutput` | `PROBARA_CAPTURE_OUTPUT` | `boolean` | `false` | Adjuntar el stdout y el stderr de cada intento como `stdout.log` y `stderr.log` | | `statusMapping` | `PROBARA_STATUS_MAPPING` | `{ passed, failed, skipped, blocked }` | ninguno | Enviar un estado como otro (`failed=blocked`) ([estados](https://docs.probara.net/es/developers/ci-integrations/playwright/results-and-retries/#mapeo-y-filtro-de-estados)) | | `statusFilter` | `PROBARA_STATUS_FILTER` | `string[]` | ninguno | No enviar ningún resultado con estos estados, después del mapeo (`skipped`) | | `resultsFile` | `PROBARA_RESULTS_FILE` | `string` | ninguno | Archivo JSON para lo que no se pudo enviar ([archivo de resultados](https://docs.probara.net/es/developers/ci-integrations/playwright/results-and-retries/#archivo-de-resultados)) | | `assignFailedTo` | `PROBARA_ASSIGN_FAILED_TO` | `string[]` | ninguno | Asignar cada resultado fallido sin responsable a uno de estos miembros, por turnos ([asignar fallos](https://docs.probara.net/es/developers/ci-integrations/playwright/results-and-retries/#asignar-los-resultados-fallidos)) | | `debug` | `PROBARA_DEBUG` | `boolean` | `false` | Registrar cada petición ([depuración](https://docs.probara.net/es/developers/ci-integrations/playwright/troubleshooting/#registro-de-depuración)) | | `rootDir` | — | `string` | el `rootDir` de Playwright | Directorio respecto al que se expresan las rutas de las claves de automatización ([claves](https://docs.probara.net/es/developers/ci-integrations/playwright/linking/#claves-de-automatización)) | | `chunkSize` | — | `number` | `500` | Resultados por petición de informe, de 1 a 500 | | `timeoutMs` | — | `number` | `30000` | Tiempo máximo de un intento HTTP, en milisegundos, de 1 a 600000 ([red](#red)) | | `maxRetries` | — | `number` | `4` | Reintentos de una petición fallida, de 0 a 10 | | `attachmentConcurrency` | — | `number` | `2` | Resultados cuyos adjuntos se suben a la vez, de 1 a 8 | El reporter envía su propio nombre y versión en el `User-Agent` (por ejemplo `probara-playwright-reporter/0.1.0 probara-core/0.2.0 node/22.12.0`); no hay ninguna opción para cambiarlo. En GitHub Actions el origen también recibe estos campos, detectados de las variables `GITHUB_*`: | Opción | Variable | Tipo | Por defecto | Qué hace | | -------------------------- | -------- | -------- | --------------------------- | ------------------------------------------------------------------------------- | | `source.provider` | — | `string` | detectado de GitHub Actions | `github_actions` (detectado) u `other` | | `source.repository` | — | `string` | detectado de GitHub Actions | Repositorio del origen de la ejecución, `owner/name` | | `source.commitAuthor` | — | `string` | detectado de GitHub Actions | Quién activó el build | | `source.pullRequestNumber` | — | `number` | detectado de GitHub Actions | Pull request del build | | `source.workflow` | — | `string` | detectado de GitHub Actions | Workflow de CI del origen de la ejecución | | `source.ciRunId` | — | `string` | detectado de GitHub Actions | Id de la ejecución de CI: los jobs de un mismo workflow comparten una ejecución | | `source.ciRunAttempt` | — | `number` | detectado de GitHub Actions | Intento de la ejecución de CI: una re-ejecución va a una ejecución propia | | `source.ciJob` | — | `string` | detectado de GitHub Actions | Job de CI del origen de la ejecución | ### Opciones de runtime Para código y pruebas, el reporter acepta también las opciones de runtime de `@probara/core`, la librería sobre la que está construido. No tienen variable, y un `playwright.config` rara vez las necesita: | Opción | Tipo | Por defecto | Qué hace | | -------- | ------------------------------ | ---------------------------- | ---------------------------------------------------------------- | | `logger` | `{ debug, info, warn, error }` | líneas `[probara]` en stderr | Dónde escribe el reporter | | `env` | `Record` | `process.env` | De dónde se leen las variables `PROBARA_*` y las del CI | | `fetch` | `function` | el `fetch` global | El cliente HTTP | | `sleep` | `function` | `setTimeout` | Las esperas entre reintentos | | `random` | `function` | `Math.random` | La variación aleatoria de la espera entre reintentos | | `now` | `function` | la hora actual | El reloj del nombre por defecto y de las fechas de `Retry-After` | ## Qué pasa con cada configuración | Configuración | Qué hace el reporter | | ----------------------------------------------------- | ----------------------------------------------------------------------------------------- | | Sin token ni proyecto, o `enabled: false` | Queda desactivado y en silencio: no envía ni registra nada (salvo en modo depuración). | | Solo uno de los dos, o un valor no válido | El envío se desactiva; se registra cada problema, y las pruebas se ejecutan como siempre. | | Un token y un proyecto, con todos los valores válidos | Envía los resultados. | Un valor del tipo equivocado, como `run.tags: 'nightly'` en lugar de una lista, es un valor no válido: ```ts reporter: [['@probara/playwright-reporter', { projectId: 'SHOP', run: { tags: 'nightly' } }]], ``` ```text $ npx playwright test [probara] Probara reporting is off: run.tags must be a list of strings ``` Los problemas nombran la opción o la variable afectada, nunca su valor, así que un token nunca aparece en el registro. ## Desactivar el envío Define `enabled: false` o `PROBARA_ENABLED=false`, u omite el token: el reporter no envía nada y queda en silencio. Los builds que no reciben secretos, como los pull requests desde forks en la mayoría de los CI, no envían nada por sí solos. Para conservar lo que una ejecución habría enviado, incluso con el envío desactivado, define un [archivo de resultados](https://docs.probara.net/es/developers/ci-integrations/playwright/results-and-retries/#archivo-de-resultados). ## URL base `baseUrl` (`PROBARA_BASE_URL`) es el host de Probara con el que habla el reporter: la URL de la aplicación, sin ruta. Por defecto es `https://app.probara.net`, y las peticiones van a ese host y a ningún otro. Déjalo sin definir salvo que Probara te indique otro host. ## Red El reporter habla HTTPS con un solo host, la URL base, desde el proceso principal de Playwright. ### Tiempos de espera | Ajuste | Por defecto | Rango | Qué limita | | ----------- | ------------------------------------ | ---------- | ----------------------------------------------------------------------- | | `timeoutMs` | 30000 ms | 1 a 600000 | Un intento de una petición, incluido el cuerpo de la respuesta | | Subidas | 120000 ms, o `timeoutMs` si es mayor | — | Un intento de subida de un adjunto (un archivo grande en una red lenta) | Un intento que agota su tiempo se reintenta como un error de red. ### Reintentos y espera | Respuesta | Qué pasa | | --------------------------------------------------------------- | ------------------------------------------------ | | Error de red, tiempo agotado, 408, 429, 500, 502, 503, 504 | Se reintenta | | 409 con `Retry-After` (la misma petición sigue en curso) | Se reintenta | | Un `201` cuyo cuerpo nunca llegó | Se reintenta; la clave de idempotencia lo repite | | Cualquier otra respuesta (400, 401, 403, 404, 409, 413, 422...) | No se reintenta: la petición falla | - `maxRetries` (de 0 a 10, 4 por defecto) fija los reintentos tras el primer intento: 5 intentos en total por defecto. - La espera antes del reintento _n_ es 1 s × 2ⁿ⁻¹, con un máximo de 30 s, más hasta un 20 % de variación aleatoria. - Una cabecera `Retry-After` (en segundos o como fecha HTTP) sustituye esa espera, con un máximo de 120 s. - Cada reintento se registra, con el intento y la espera. Con los valores por defecto, una petición que sigue fallando se abandona tras unos 15 s de espera (1 + 2 + 4 + 8 s, hasta 18 s con la variación), más los propios intentos, cada uno de como mucho `timeoutMs`. El peor caso es un `Retry-After` en cada respuesta: 120 s antes de cada reintento, es decir, 8 minutos de espera con los 4 reintentos por defecto (20 minutos con `maxRetries: 10`). Eso es por petición, y un informe fallido detiene los siguientes de su proyecto. Playwright espera al reporter antes de terminar, así que baja `maxRetries` o `timeoutMs` para acotar un paso de CI. ### Límite de tasa Probara limita las peticiones a la API por organización (60 peticiones por minuto en Free, 1.200 en Pro y 3.000 en Enterprise), sumando todos los tokens de la organización. Lo que cuesta una ejecución: | Petición | Cuántas | | ------------------------ | --------------------------------------------------------------------------- | | Informe | 1 por chunk de hasta 500 resultados (`chunkSize`) | | Preparación de adjuntos | 1 por resultado con archivos (por cada 20 archivos o 64 MiB) | | Confirmación de adjuntos | 1 por resultado con archivos | | Cierre | 1, si había adjuntos en cola (si no, el último informe cierra la ejecución) | Una ejecución de 2000 intentos sin archivos cuesta 4 peticiones; una en la que 100 intentos tienen una traza cuesta unas 200 más. Las respuestas `429` se reintentan tras su `Retry-After`. Para repartir las subidas, baja `attachmentConcurrency`; para enviar menos archivos, conserva las trazas y los vídeos solo de los fallos (`retain-on-failure`) o define `uploadAttachments: false`. ### Chunks y orden - Los resultados salen en chunks de `chunkSize` (de 1 a 500, 500 por defecto), **uno tras otro**, en el orden en que terminaron los intentos. Un caso de la ejecución conserva el último resultado registrado, así que el orden importa. Cada chunk respeta además los totales de pasos y etiquetas por informe de Probara. - El primer chunk crea la ejecución (salvo que `run.ulid` indique una); los demás la reutilizan. - Cuando un chunk falla tras sus reintentos, los chunks siguientes de ese proyecto no se envían y la ejecución queda abierta; un [archivo de resultados](https://docs.probara.net/es/developers/ci-integrations/playwright/results-and-retries/#archivo-de-resultados) los conserva. - Las subidas empiezan cuando su informe se ha registrado, `attachmentConcurrency` resultados a la vez (de 1 a 8, 2 por defecto), y la ejecución se cierra después de las subidas. ### Idempotencia Cada informe, creación de ejecución, cierre de ejecución y confirmación de adjuntos lleva una `Idempotency-Key`, la misma en cada reintento de esa petición. Si el primer intento de un informe reintentado sí se registró, Probara lo repite, nunca lo registra dos veces ([idempotencia](https://docs.probara.net/es/developers/api/idempotency/)). Ejecutar `playwright test` otra vez es una ejecución nueva, con cada resultado registrado de nuevo. ### Proxies El reporter usa el `fetch` integrado en Node y no tiene ninguna opción de proxy propia: | Node.js | Soporte de proxy | | --------------------------------- | ----------------------------------------------------------------------------------------- | | 22.21 o posterior, 24 o posterior | Define `NODE_USE_ENV_PROXY=1` con `HTTPS_PROXY` (y `NO_PROXY`); `fetch` pasa por el proxy | | 22.12 a 22.20 | Sin soporte: `fetch` ignora `HTTPS_PROXY` y `HTTP_PROXY` | ```bash NODE_USE_ENV_PROXY=1 HTTPS_PROXY=http://proxy.example.com:8080 npx playwright test ``` El ajuste se aplica a todo el proceso de Node ([documentación de Node](https://nodejs.org/api/cli.html#node_use_env_proxy1)): añade `localhost` a `NO_PROXY` si tus pruebas llegan a un servidor local con `fetch`. En versiones anteriores de Node, actualiza Node o permite `app.probara.net` en el firewall. ### Autoridades de certificación propias Cuando tu red inspecciona TLS con una autoridad de certificación privada (un proxy corporativo, por ejemplo), pasa a Node el certificado de la CA (PEM) al arrancar: ```bash NODE_EXTRA_CA_CERTS=/etc/ssl/certs/company-ca.pem npx playwright test ``` Node lee `NODE_EXTRA_CA_CERTS` una sola vez al arrancar, así que defínela en el entorno del paso. Desde Node 22.19, `NODE_USE_SYSTEM_CA=1` confía en cambio en el almacén de certificados del sistema operativo. No hay ninguna opción para desactivar la verificación TLS. Siguiente: [vincula tus pruebas con casos](https://docs.probara.net/es/developers/ci-integrations/playwright/linking/), o consulta las [opciones de la ejecución](https://docs.probara.net/es/developers/ci-integrations/playwright/results-and-retries/#opciones-de-la-ejecución).