Integraciones: Jira, Xray, Azure DevOps, Slack y Telegram

Nexus Studio se conecta con cinco servicios: Jira Cloud, Xray Cloud, Azure DevOps, Slack y Telegram. Cada uno está apagado hasta que lo activas, y cada uno se contacta directo desde tu máquina, nunca a través de nuestros servidores. Esta página explica qué hace cada uno, qué claves lee y qué no hace nunca.

Por el equipo de Nexus Studio, Verdict System LLC. 9 de octubre de 2026.

Cómo funciona cada integración

• Apagado hasta que lo activas. Cada servicio tiene su propio interruptor: JIRA_ENABLED, XRAY_ENABLED, AZURE_BOARDS_ENABLED, SLACK_ENABLED y TELEGRAM_ENABLED. Todos valen false por defecto.
• Directo desde tu máquina. El motor llama a la API de cada servicio desde la máquina que ejecuta las pruebas. Nada pasa por nuestros servidores, y nunca vemos tus incidencias, alertas ni resultados.
• Las claves se quedan en el workspace. Los tokens y las claves son líneas del archivo .env del workspace, en tu disco. Settings, en Integrations, los edita y muestra cada token, clave y webhook ocultos.
• Las ejecuciones de sandbox quedan fuera. Una ejecución de sandbox es una prueba en construcción, no un hallazgo: nunca abre, comenta ni cierra una incidencia.

Una incidencia por prueba, mientras siga rota

Jira y Azure Boards siguen el mismo ciclo de vida. La incidencia pertenece a la prueba, no a la ejecución, así que una prueba que falla cada noche es una incidencia con su historial, no una incidencia nueva cada noche.

1. La primera falla abre una incidencia. Una ejecución que termina en BREACHED, BREACHED_FLAKY, CHAOS_BREACHED o TIMEOUT abre una incidencia para esa prueba, con el error y la captura de pantalla de la falla adjuntos.
2. Una falla repetida la comenta. Mientras esa incidencia esté abierta, la siguiente falla le agrega un comentario, con la nueva captura adjunta. Dos navegadores que fallan a la vez escriben en la misma incidencia.
3. Una pasada limpia la cierra. Cuando la prueba pasa limpia en todos los navegadores de una ejecución, la incidencia recibe un comentario que lo dice y pasa a su estado de terminada. Si el flujo de trabajo no tiene esa transición o ese estado, recibe solo el comentario.
4. Una falla posterior abre una incidencia nueva. También la abre una falla cuya incidencia fue borrada o movida.

Adjuntos: solo la captura de pantalla, por defecto. La traza de Playwright y el log de la ejecución se adjuntan también solo si lo activas con NEXUS_ISSUE_ATTACH_TRACE=true en Settings, porque pueden contener datos de sesión: cookies, cabeceras de autorización y contraseñas escritas. Cada archivo se adjunta hasta 10 MB.

FLAKY nunca abre nada: una ejecución que falló y luego pasó al reintentar no es un bug. Tampoco BLOCKED, UNREACHABLE, CRASHED ni un error de configuración, que hablan del entorno, no de tu aplicación (cómo se deciden los veredictos). Qué incidencia corresponde a qué prueba se guarda en evidence/integrations/issue-map.json, en el workspace.

Jira Cloud

• Conexión: el correo de tu cuenta de Atlassian y un token de API, creado en id.atlassian.com. En Settings, en Integrations, pega cualquier enlace de tu sitio de Jira: el Studio guarda el sitio y la clave del proyecto. La dirección del sitio, JIRA_BASE_URL, debe ser https. Check connection los prueba y no crea nada.
• Incidencias: un Bug en JIRA_PROJECT_KEY, con el ciclo de vida de arriba. En una pasada limpia, la incidencia pasa por la transición nombrada en JIRA_DONE_TRANSITION, Done por defecto, buscada por nombre sin distinguir mayúsculas.
• Sin duplicados: si en las últimas 24 horas se creó un Bug con el mismo resumen, no se abre un segundo.
• A mano: el Evidence Locker puede enviar una falla a Jira cuando tú lo decides.

Xray Cloud

Con XRAY_ENABLED=true, cada ejecución de nexus ci importa su JUnit XML en Xray Cloud como una Test Execution, en XRAY_PROJECT_KEY, o en JIRA_PROJECT_KEY si está vacío, y bajo el Test Plan de XRAY_TEST_PLAN_KEY si defines uno.

• Conexión: un par de claves de API, XRAY_CLIENT_ID y XRAY_CLIENT_SECRET, creado en Jira en Apps, Xray, Global settings, API keys.
• Qué sale: el archivo JUnit de esa ejecución, y nada más. Un archivo JUnit que dejó una ejecución anterior nunca se importa.
• Nunca hace fallar la ejecución: si la importación falla, el log de la ejecución dice por qué en una línea, con el secreto borrado.

Azure DevOps: Boards, Test Plans y Pipelines

Un token de acceso personal (PAT) y un proyecto, en AZURE_DEVOPS_ORG_URL (https://dev.azure.com/<org> o https://<org>.visualstudio.com) y AZURE_DEVOPS_PROJECT. El PAT se envía solo a los hosts propios de Azure DevOps y nunca aparece en una línea de log. En Settings, en Integrations, Connect Azure DevOps comprueba el proyecto y el tipo de work item, y no crea nada.

• Azure Boards: con AZURE_BOARDS_ENABLED=true, una falla abre un work item del tipo AZURE_BOARDS_WORK_ITEM_TYPE, Bug por defecto, con el ciclo de vida de arriba. En una pasada limpia pasa al estado de AZURE_BOARDS_DONE_STATE, Resolved por defecto; un proceso que rechaza ese estado recibe solo el comentario. El PAT necesita Work Items (Read & write). El Evidence Locker también puede enviar una falla a Azure Boards a mano.
• Azure Test Plans: el azure-pipelines.yml que genera la pantalla CI/CD publica el JUnit XML de la ejecución con la tarea PublishTestResults@2, así que cada ejecución del pipeline aparece en Test Plans, Runs.
• Azure Pipelines: nexus ci-remote --provider=azure encola una ejecución del pipeline de AZURE_PIPELINE_ID, la espera y trae su JUnit XML de vuelta a esta máquina. Para esto el PAT necesita Build (Read & execute).

Slack

• Conexión: una URL de Incoming Webhook, en SLACK_WEBHOOK_URL. Settings tiene un botón Send test message.
• Qué recibe: mensajes de Block Kit: el resumen de la ejecución y, con NEXUS_SLACK_NOTIFY=true, un mensaje por cada prueba que falla, es flaky, de caos o de regresión visual. Un mensaje sobre una falla enlaza su incidencia de Jira cuando la hay.
• A mano: el Evidence Locker puede publicar en Slack el resumen en texto de una falla. Slack no recibe archivos.

Telegram

• Conexión: un bot propio, creado una vez con @BotFather, en TELEGRAM_TOKEN. En Settings, Connect by QR vincula tu chat y llena TELEGRAM_CHAT_ID. No hay bot compartido.
• Qué recibe: alertas de falla, una por prueba con NEXUS_TELEGRAM_NOTIFY=true, y los reportes y archivos que eliges compartir desde el Studio.
• Antes de activarlo: Telegram puede recibir archivos, como reportes y PDF, y van a los servidores de Telegram. En un entorno regulado, consulta primero a tu equipo de cumplimiento.

Las claves

Cada clave es una línea del .env del workspace. Settings las edita todas.

En un pipeline, las mismas claves, todas menos AZURE_PIPELINE_ID, son variables secretas del pipeline, y una clave que dejas sin definir mantiene su servicio apagado (secretos en CI/CD).

Preguntas

¿Nexus Studio ve mis datos de Jira o de Azure DevOps?

No. El motor habla con Jira, Xray, Azure DevOps, Slack y Telegram desde tu máquina, con tus claves. Nada de eso pasa por nuestros servidores.

¿Una prueba flaky abre un ticket?

No. FLAKY no abre nada. BREACHED_FLAKY sí: la falla misma fue inconsistente, y un reintento no la esconde.

Una prueba falló 30 veces esta semana. ¿Cuántas incidencias son?

Una, con un comentario y una captura nueva por cada falla después de la primera, hasta que la prueba pasa limpia en todos los navegadores.

¿Puedo usar Jira y Azure Boards a la vez?

Sí. Cada uno mantiene su propia incidencia por prueba.