Integrations: Jira, Xray, Azure DevOps, Slack e Telegram

O Nexus Studio se conecta a cinco serviços: Jira Cloud, Xray Cloud, Azure DevOps, Slack e Telegram. Cada um fica desativado até você ativá-lo, e cada um é acessado diretamente da sua máquina, nunca pelos nossos servidores. Esta página explica o que cada um faz, as chaves que ele lê e o que ele nunca faz.

Pela equipe do Nexus Studio, Verdict System LLC. 9 de outubro de 2026.

Como funcionam todas as integrações

• Desativado até você ativar. Cada serviço tem seu próprio interruptor: JIRA_ENABLED, XRAY_ENABLED, AZURE_BOARDS_ENABLED, SLACK_ENABLED e TELEGRAM_ENABLED. Todos são false por padrão.
• Diretamente da sua máquina. O engine chama a API de cada serviço a partir da máquina que executa os testes. Nada passa pelos nossos servidores, e nunca vemos suas issues, alertas ou resultados.
• As chaves ficam no workspace. Tokens e chaves são linhas no arquivo .env do workspace, no seu disco. Settings, em Integrations, as edita e mostra todo token, chave e webhook ocultado.
• Execuções no sandbox ficam de fora. Uma execução no sandbox é um teste em construção, não um achado: ela nunca abre, comenta nem fecha uma issue.

Uma issue por teste, enquanto ele continuar falhando

Jira e Azure Boards seguem o mesmo ciclo de vida. A issue pertence ao teste, não à execução, então um teste que falha toda noite é uma issue com histórico, não uma issue nova a cada noite.

1. A primeira falha abre uma issue. Uma execução que termina em BREACHED, BREACHED_FLAKY, CHAOS_BREACHED ou TIMEOUT abre uma issue para aquele teste, com o erro e a captura de tela da falha anexados.
2. Uma falha repetida comenta nela. Enquanto essa issue estiver aberta, a próxima falha adiciona um comentário a ela, com a nova captura de tela anexada. Dois navegadores que falham ao mesmo tempo contribuem para a mesma issue.
3. Uma aprovação limpa a fecha. Quando o teste passa sem falhas em todos os navegadores de uma execução, a issue recebe um comentário informando isso e passa para o estado de concluída. Se o workflow não tiver essa transição ou estado, ela recebe apenas o comentário.
4. Uma falha depois disso abre uma nova issue. O mesmo vale para uma falha cuja issue foi excluída ou movida.

Anexos: apenas a captura de tela, por padrão. O trace do Playwright e o log da execução só são anexados também se você ativar com NEXUS_ISSUE_ATTACH_TRACE=true em Settings, pois podem conter dados de sessão: cookies, cabeçalhos de autorização e senhas digitadas. Cada arquivo é anexado até 10 MB.

FLAKY nunca abre nada: uma execução que falhou e depois passou em uma nova tentativa não é um bug. BLOCKED, UNREACHABLE, CRASHED e erro de configuração também não, pois dizem respeito ao ambiente, não à sua aplicação (como os veredictos são decididos). A qual teste pertence cada issue fica registrado em evidence/integrations/issue-map.json, no workspace.

Jira Cloud

• Conectar: o e-mail da sua conta Atlassian e um token de API, criado em id.atlassian.com. Em Settings, em Integrations, cole qualquer link do seu site Jira: o Studio guarda o site e a chave do projeto. O endereço do site, JIRA_BASE_URL, deve ser https. Check connection os testa e não cria nada.
• Issues: um Bug em JIRA_PROJECT_KEY, seguindo o ciclo de vida acima. Em uma aprovação limpa, a issue passa pela transição indicada em JIRA_DONE_TRANSITION, Done por padrão, comparada pelo nome, sem diferenciar maiúsculas de minúsculas.
• Sem duplicatas: se um Bug com o mesmo resumo foi criado nas últimas 24 horas, nenhum segundo é aberto.
• Manualmente: o Evidence Locker pode enviar uma falha ao Jira quando você escolher.

Xray Cloud

Com XRAY_ENABLED=true, cada execução de nexus ci importa seu JUnit XML no Xray Cloud como uma Test Execution, em XRAY_PROJECT_KEY, ou em JIRA_PROJECT_KEY quando ele estiver em branco, e sob o Test Plan em XRAY_TEST_PLAN_KEY quando você definir um.

• Conectar: um par de chaves de API, XRAY_CLIENT_ID e XRAY_CLIENT_SECRET, criado no Jira em Apps, Xray, Global settings, API keys.
• O que sai: o arquivo JUnit dessa execução, e nada mais. Um arquivo JUnit deixado por uma execução anterior nunca é importado.
• Nunca faz a execução falhar: se a importação falhar, o log da execução explica o motivo em uma linha, com o segredo ocultado.

Azure DevOps: Boards, Test Plans e Pipelines

Um personal access token (PAT) e um projeto, em AZURE_DEVOPS_ORG_URL (https://dev.azure.com/<org> ou https://<org>.visualstudio.com) e AZURE_DEVOPS_PROJECT. O PAT é enviado apenas aos hosts do próprio Azure DevOps e nunca aparece em uma linha de log. Em Settings, em Integrations, Connect Azure DevOps verifica o projeto e o tipo de work item, e não cria nada.

• Azure Boards: com AZURE_BOARDS_ENABLED=true, uma falha abre um work item do tipo AZURE_BOARDS_WORK_ITEM_TYPE, Bug por padrão, seguindo o ciclo de vida acima. Em uma aprovação limpa, ele passa para o estado indicado em AZURE_BOARDS_DONE_STATE, Resolved por padrão; um processo que recusa esse estado recebe apenas o comentário. O PAT precisa de Work Items (Read & write). O Evidence Locker também pode enviar uma falha ao Azure Boards manualmente.
• Azure Test Plans: o azure-pipelines.yml que a tela CI/CD gera publica o JUnit XML da execução com a tarefa PublishTestResults@2, de modo que cada execução do pipeline aparece em Test Plans, Runs.
• Azure Pipelines: nexus ci-remote --provider=azure enfileira uma execução do pipeline em AZURE_PIPELINE_ID, aguarda sua conclusão e traz o JUnit XML de volta para esta máquina. O PAT precisa de Build (Read & execute) para isso.

Slack

• Conectar: uma URL de Incoming Webhook, em SLACK_WEBHOOK_URL. Settings tem um botão Send test message.
• O que ele recebe: mensagens Block Kit: o resumo da execução e, com NEXUS_SLACK_NOTIFY=true, uma mensagem por teste com falha, flaky, de chaos ou com regressão visual. Uma mensagem sobre uma falha inclui o link da issue do Jira quando houver uma.
• Manualmente: o Evidence Locker pode publicar no Slack o resumo em texto de uma falha. O Slack não recebe arquivos.

Telegram

• Conectar: um bot seu, criado uma única vez com @BotFather, em TELEGRAM_TOKEN. Em Settings, Connect by QR pareia seu chat e preenche TELEGRAM_CHAT_ID. Não existe bot compartilhado.
• O que ele recebe: alertas de falha, um por teste com NEXUS_TELEGRAM_NOTIFY=true, e os relatórios e arquivos que você escolher compartilhar a partir do Studio.
• Antes de ativar: o Telegram pode receber arquivos, como relatórios e PDFs, e eles vão para os servidores do Telegram. Em um ambiente regulado, consulte antes sua equipe de compliance.

As chaves

Cada chave é uma linha no .env do workspace. Settings edita todas elas.

Em um pipeline, as mesmas chaves, exceto AZURE_PIPELINE_ID, são as variáveis secretas do pipeline, e uma chave que você deixa sem definir mantém o serviço desativado (secrets em CI/CD).

Perguntas

O Nexus Studio acessa meus dados do Jira ou do Azure DevOps?

Não. O engine se comunica com Jira, Xray, Azure DevOps, Slack e Telegram a partir da sua máquina, com as suas chaves. Nada disso passa pelos nossos servidores.

Um teste FLAKY abre um ticket?

Não. FLAKY não registra nada. BREACHED_FLAKY registra: a falha em si foi inconsistente, e uma nova tentativa não a esconde.

Um teste falhou 30 vezes nesta semana. Quantas issues isso gera?

Uma, com um comentário e uma nova captura de tela para cada falha depois da primeira, até o teste passar limpo em todos os navegadores.

Posso usar Jira e Azure Boards ao mesmo tempo?

Sim. Cada um mantém a sua própria issue por teste.