Integracje: Jira, Xray, Azure DevOps, Slack i Telegram

Nexus Studio łączy się z pięcioma usługami: Jira Cloud, Xray Cloud, Azure DevOps, Slack i Telegram. Każda z nich pozostaje wyłączona, dopóki jej nie włączysz, a połączenie odbywa się bezpośrednio z Twojego komputera, nigdy przez nasze serwery. Ta strona wyjaśnia, co robi każda z usług, jakie klucze odczytuje i czego nigdy nie robi.

Autor: zespół Nexus Studio, Verdict System LLC. 9 października 2026.

Jak działa każda integracja

• Wyłączona, dopóki jej nie włączysz. Każda usługa ma własny przełącznik: JIRA_ENABLED, XRAY_ENABLED, AZURE_BOARDS_ENABLED, SLACK_ENABLED i TELEGRAM_ENABLED. Domyślna wartość każdego z nich to false.
• Bezpośrednio z Twojego komputera. Silnik wywołuje API każdej usługi z komputera, na którym uruchamiane są testy. Nic nie przechodzi przez nasze serwery i nigdy nie widzimy Twoich zgłoszeń, alertów ani wyników.
• Klucze pozostają w obszarze roboczym. Tokeny i klucze są zapisane jako wiersze w pliku .env obszaru roboczego, na Twoim dysku. W Ustawieniach, w sekcji Integracje, możesz je edytować, a wszystkie tokeny, klucze i webhooki są wyświetlane w zamaskowanej postaci.
• Uruchomienia w piaskownicy są pomijane. Uruchomienie w piaskownicy to test w trakcie tworzenia, a nie wykryty problem: nigdy nie tworzy zgłoszeń, nie komentuje ich ani nie zamyka.

Jedno zgłoszenie na test, dopóki test się nie powiedzie

Jira i Azure Boards stosują ten sam cykl obsługi zgłoszeń. Zgłoszenie jest przypisane do testu, nie do uruchomienia, więc test kończący się niepowodzeniem każdej nocy ma jedno zgłoszenie z historią, zamiast nowego zgłoszenia co noc.

1. Pierwsze niepowodzenie otwiera jedno zgłoszenie. Uruchomienie zakończone statusem BREACHED, BREACHED_FLAKY, CHAOS_BREACHED lub TIMEOUT otwiera jedno zgłoszenie dla danego testu, z opisem błędu i załączonym zrzutem ekranu z momentu niepowodzenia.
2. Kolejne niepowodzenie dodaje do niego komentarz. Dopóki zgłoszenie jest otwarte, następne niepowodzenie dodaje do niego komentarz z nowym zrzutem ekranu w załączniku. Niepowodzenia w dwóch przeglądarkach jednocześnie trafiają do tego samego zgłoszenia.
3. Pełne powodzenie zamyka zgłoszenie. Gdy test przejdzie bez problemów we wszystkich przeglądarkach w danym uruchomieniu, do zgłoszenia trafia odpowiedni komentarz i zostaje ono przeniesione do stanu zakończonego. Jeśli przepływ pracy nie ma takiego przejścia lub stanu, dodawany jest tylko komentarz.
4. Późniejsze niepowodzenie otwiera nowe zgłoszenie. Tak samo dzieje się w przypadku niepowodzenia, którego zgłoszenie zostało usunięte lub przeniesione.

Załączniki: domyślnie tylko zrzut ekranu. Ślad Playwright i dziennik uruchomienia są dołączane wyłącznie po wyrażeniu zgody przez ustawienie NEXUS_ISSUE_ATTACH_TRACE=true w Ustawieniach, ponieważ mogą zawierać dane sesji: pliki cookie, nagłówki autoryzacji i wpisane hasła. Każdy plik jest dołączany, jeśli nie przekracza 10 MB.

FLAKY nigdy nie tworzy zgłoszeń: uruchomienie, które zakończyło się niepowodzeniem, a następnie powiodło się przy ponownej próbie, nie oznacza błędu. Zgłoszeń nie tworzą też statusy BLOCKED, UNREACHABLE, CRASHED ani błąd konfiguracji, ponieważ dotyczą środowiska, a nie Twojej aplikacji (jak ustalane są werdykty). Powiązania zgłoszeń z testami są przechowywane w pliku evidence/integrations/issue-map.json w obszarze roboczym.

Jira Cloud

• Połączenie: adres e-mail Twojego konta Atlassian i token API utworzony na id.atlassian.com. W Ustawieniach, w sekcji Integracje, wklej dowolny link ze swojej witryny Jira: Studio zachowa adres witryny i klucz projektu. Adres witryny, JIRA_BASE_URL, musi używać https. Opcja Sprawdź połączenie weryfikuje te dane i niczego nie tworzy.
• Zgłoszenia: zgłoszenie typu Bug w projekcie JIRA_PROJECT_KEY, zgodnie z opisanym powyżej cyklem. Po przejściu testu bez problemów zgłoszenie przechodzi przez przejście o nazwie określonej w JIRA_DONE_TRANSITION, domyślnie Done, dopasowywanej bez rozróżniania wielkości liter.
• Bez duplikatów: jeśli w ciągu ostatnich 24 godzin utworzono zgłoszenie typu Bug o tym samym podsumowaniu, drugie nie zostanie utworzone.
• Ręcznie: Evidence Locker może przesłać niepowodzenie do Jira, gdy tak zdecydujesz.

Xray Cloud

Przy ustawieniu XRAY_ENABLED=true każde uruchomienie nexus ci importuje swój plik JUnit XML do Xray Cloud jako Test Execution, w projekcie XRAY_PROJECT_KEY lub JIRA_PROJECT_KEY, gdy pierwsza wartość jest pusta, oraz w ramach Test Plan wskazanego w XRAY_TEST_PLAN_KEY, jeśli go ustawisz.

• Połączenie: para kluczy API, XRAY_CLIENT_ID i XRAY_CLIENT_SECRET, utworzona w Jira w sekcji Aplikacje, Xray, Ustawienia globalne, Klucze API.
• Co jest wysyłane: plik JUnit z danego uruchomienia i nic więcej. Plik JUnit pozostały po wcześniejszym uruchomieniu nigdy nie jest importowany.
• Nigdy nie powoduje niepowodzenia uruchomienia: jeśli import się nie powiedzie, dziennik uruchomienia podaje przyczynę w jednym wierszu, z ukrytym sekretem.

Azure DevOps: Boards, Test Plans i Pipelines

Jeden osobisty token dostępu (PAT) i jeden projekt, w AZURE_DEVOPS_ORG_URL (https://dev.azure.com/<org> lub https://<org>.visualstudio.com) i AZURE_DEVOPS_PROJECT. Token PAT jest wysyłany wyłącznie do hostów należących do Azure DevOps i nigdy nie pojawia się w dzienniku. W Ustawieniach, w sekcji Integracje, opcja Połącz z Azure DevOps sprawdza projekt i typ elementu roboczego, ale niczego nie tworzy.

• Azure Boards: przy ustawieniu AZURE_BOARDS_ENABLED=true niepowodzenie powoduje otwarcie elementu roboczego typu AZURE_BOARDS_WORK_ITEM_TYPE, domyślnie Bug, zgodnie z opisanym powyżej cyklem życia. Gdy test zakończy się pomyślnie bez zastrzeżeń, element przechodzi do stanu określonego w AZURE_BOARDS_DONE_STATE, domyślnie Resolved; jeśli proces nie dopuszcza tego stanu, dodawany jest tylko komentarz. Token PAT wymaga uprawnienia Work Items (Read & write). Z Evidence Locker można też ręcznie wysłać informację o niepowodzeniu do Azure Boards.
• Azure Test Plans: plik azure-pipelines.yml generowany na ekranie CI/CD publikuje plik JUnit XML z uruchomienia za pomocą zadania PublishTestResults@2, dzięki czemu każde uruchomienie potoku pojawia się w Test Plans, w sekcji Runs.
• Azure Pipelines: polecenie nexus ci-remote --provider=azure kolejkuje uruchomienie potoku wskazanego w AZURE_PIPELINE_ID, czeka na jego zakończenie i pobiera jego plik JUnit XML na ten komputer. Token PAT wymaga do tego uprawnienia Build (Read & execute).

Slack

• Połączenie: jeden adres URL przychodzącego webhooka, w SLACK_WEBHOOK_URL. W Ustawieniach znajduje się przycisk Wyślij wiadomość testową.
• Co otrzymuje: wiadomości Block Kit: podsumowanie uruchomienia, a przy ustawieniu NEXUS_SLACK_NOTIFY=true także osobną wiadomość dla każdego testu zakończonego niepowodzeniem, niestabilnego, testu chaosu lub regresji wizualnej. Wiadomość o niepowodzeniu zawiera odnośnik do zgłoszenia w Jira, jeśli takie istnieje.
• Ręcznie: z Evidence Locker można opublikować w Slack tekstowe podsumowanie niepowodzenia. Do Slack nie są wysyłane żadne pliki.

Telegram

• Połączenie: własny bot, utworzony jednorazowo za pomocą @BotFather, w TELEGRAM_TOKEN. W Ustawieniach opcja Połącz za pomocą kodu QR łączy czat i uzupełnia TELEGRAM_CHAT_ID. Nie ma wspólnego bota.
• Co otrzymuje: alerty o niepowodzeniach, po jednym na test przy ustawieniu NEXUS_TELEGRAM_NOTIFY=true, oraz raporty i pliki wybrane do udostępnienia ze Studio.
• Przed włączeniem: Telegram może otrzymywać pliki, takie jak raporty i pliki PDF, które trafiają na serwery Telegram. W środowisku objętym regulacjami najpierw skonsultuj się z zespołem ds. zgodności.

Klucze

Każdy klucz to osobny wiersz w pliku .env obszaru roboczego. Wszystkie można edytować w Ustawieniach.

W potoku te same klucze, z wyjątkiem AZURE_PIPELINE_ID, są jego tajnymi zmiennymi, a pozostawienie klucza bez wartości powoduje, że odpowiadająca mu usługa pozostaje wyłączona (sekrety w CI/CD).

Pytania

Czy Nexus Studio widzi moje dane z Jira lub Azure DevOps?

Nie. Silnik łączy się z Jira, Xray, Azure DevOps, Slack i Telegram z Twojego komputera, używając Twoich kluczy. Żadne z tych danych nie przechodzą przez nasze serwery.

Czy niestabilny test utworzy zgłoszenie?

Nie. FLAKY nie tworzy zgłoszeń. BREACHED_FLAKY je tworzy: samo niepowodzenie występowało nieregularnie, a ponowienie próby go nie ukrywa.

Test nie powiódł się 30 razy w tym tygodniu. Ile to zgłoszeń?

Jedno, z komentarzem i nowym zrzutem ekranu dla każdego niepowodzenia po pierwszym, aż test przejdzie bez problemów we wszystkich przeglądarkach.

Czy mogę korzystać z Jira i Azure Boards jednocześnie?

Tak. Każde z nich utrzymuje własne zgłoszenie dla danego testu.