Configuración del reporter de Playwright

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

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=<ulid>,API=<ulid>).
• 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.

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:

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)
run.ulid	PROBARA_RUN_ULID	string	ninguno: una ejecución nueva	Enviar a una ejecución existente (shards)
run.name	PROBARA_RUN_NAME	string	el nombre del build de CI, si no Automated run <date>	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)
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<string, string>	ninguno	La ejecución que reutilizar en cada proyecto (WEB=<ulid>,API=<ulid>) (varios proyectos)
projects	PROBARA_PROJECTS	string[]	ninguno	Otros proyectos a los que pueden ir los resultados (WEB,API) (varios proyectos)
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)
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<string, boolean>	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)
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)
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)
assignFailedTo	PROBARA_ASSIGN_FAILED_TO	string[]	ninguno	Asignar cada resultado fallido sin responsable a uno de estos miembros, por turnos (asignar fallos)
debug	PROBARA_DEBUG	boolean	false	Registrar cada petición (depuración)
rootDir	—	string	el rootDir de Playwright	Directorio respecto al que se expresan las rutas de las claves de automatización (claves)
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)
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<string, string>	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:

reporter: [['@probara/playwright-reporter', { projectId: 'SHOP', run: { tags: 'nightly' } }]],

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

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

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

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, o consulta las opciones de la ejecución.