Uruchamiaj testy z CI/CD

Ekran CI/CD w Studio tworzy plik potoku dla GitHub Actions lub GitLab CI. Ten przewodnik opisuje, co uruchamia ten plik, trzy miejsca, w których można uruchomić zadanie, sekrety, generowany plik JUnit XML i materiały dowodowe oraz błędy występujące na komputerze CI.

Plik potoku

Na ekranie CI/CD wybierz GitHub Actions lub GitLab CI, przeglądarki, kontrole i miejsce uruchamiania zadania, a następnie wygeneruj plik. Studio najpierw sprawdza poprawność pliku lokalnie, a z tego samego ekranu może też utworzyć commit i wysłać go do repozytorium zdalnego. W terminalu polecenie nexus init --ci github lub nexus init --ci gitlab tworzy taki sam plik.

W przypadku wielu przeglądarek GitHub uruchamia osobne zadanie dla każdej z nich, z ustawieniem fail-fast: false, a każde zadanie dodaje --project=<browser>. Wybrane kontrole dodają --visual, --a11y, --chaos=, --loop= lub --no-retry.

Kody zakończenia i JUnit XML

nexus ci uruchamia wskazane testy (TC1,TC2) lub wszystkie przy użyciu --all i kończy działanie z kodem 0, gdy testy przejdą pomyślnie, 1 w razie niepowodzenia i 2, gdy nic nie uruchomiono lub polecenie było nieprawidłowe. Zapisuje JUnit XML w evidence/ci/junit.xml; --junit=<path> zapisuje go w innym miejscu.

Miejsce uruchamiania zadania: trzy opcje

Każda opcja wymaga komputera z aktywacją: silnik nie uruchamia zestawów testów na komputerze bez aktywacji, a każdy aktywowany komputer wlicza się do limitu Twojego planu (plany i komputery). Runner w chmurze, runs-on: ubuntu-latest, uruchamia nową maszynę wirtualną dla każdego zadania, więc nigdy nie zachowuje aktywacji; użyj własnego runnera działającego na stałym komputerze.

Opcja A: własny runner na komputerze ze Studio

1. Na komputerze PC lub mini PC z Windows 11, na którym zainstalowano i aktywowano Nexus Studio, zarejestruj runnera: w GitHub, w repozytorium, wybierz Ustawienia, Actions, Runnery, Nowy własny runner; w GitLab wybierz Ustawienia, CI/CD, Runnery.
2. Na ekranie CI/CD wybierz Mój komputer. Plik będzie wtedy zawierał runs-on: [self-hosted] w GitHub lub tags: [self-hosted] w GitLab.
3. Uruchom runnera jako użytkownik systemu Windows, który aktywował Studio. Silnik odczytuje aktywację z profilu tego użytkownika, z pliku .sentinel-studio\license.json, więc usługa runnera działająca na innym koncie jej nie znajdzie.

Zadanie korzysta z aktywacji tego komputera: jedna aktywacja na komputer, już uwzględniona w Twoim planie, bez klucza w potoku. Używaj runnera na własnej infrastrukturze wyłącznie z prywatnym repozytorium, zgodnie z ostrzeżeniem Studio: w publicznym repozytorium każdy, kto otworzy żądanie scalenia, może uruchomić kod na Twoim komputerze.

Opcja B: runner na serwerze VPS, w kontenerze

Serwer VPS z systemem Ubuntu 24.04 LTS x86_64, Docker Engine i Compose v2, z dostępem przez SSH z uwierzytelnianiem kluczem. Liczy się jako jeden komputer w Twoim planie.

1. Na ekranie CI/CD wybierz Mój komputer + Docker. Oprócz pliku potoku Studio zapisuje w obszarze roboczym pliki docker-compose.sentinel-runner.yml, Dockerfile.runner oraz dwa skrypty startowe runnera. Dockerfile.runner bazuje na obrazie mcr.microsoft.com/playwright:v1.62.1-noble.
2. Na ekranie widać polecenia do wklejenia w sesji SSH na serwerze VPS, a nie w terminalu samego Studio. W przypadku GitHub pobierany jest token rejestracyjny ważny przez 1 godzinę i ustawiane są zmienne REPO_URL, RUNNER_TOKEN i RUNNER_NAME; w przypadku GitLab, GITLAB_URL i GITLAB_RUNNER_TOKEN. Następnie:

docker compose -f docker-compose.sentinel-runner.yml up -d --build sentinel-runner
docker compose -f docker-compose.sentinel-runner.yml up -d sentinel-runner-gitlab

Pierwszy wiersz dotyczy GitHub, drugi GitLab. W kontenerze z systemem Linux licencja identyfikuje komputer na podstawie /etc/machine-id: zamontuj ten plik z hosta tylko do odczytu, /etc/machine-id:/etc/machine-id:ro, a folder .sentinel-studio z katalogu domowego runnera przechowuj na woluminie, aby zachować aktywację po ponownym zbudowaniu obrazu. Aktywuj raz, ręcznie, za pomocą nexus license activate i swojego klucza, nigdy z pliku potoku.

Obecnie obraz runnera jest budowany na serwerze VPS na podstawie Dockerfile.runner. Repozytorium nie ma jeszcze rejestru kontenerów: obraz opublikowany w GitHub Container Registry, z którego korzysta środowisko wykonawcze VPS w Studio, pojawi się w następnej wersji.

Opcja C: zadanie CI uruchamia wykonanie na hoście przez SSH

Zadanie pozostaje niewielkie, niezależnie od środowiska wykonawczego, a zestawy testów działają na Twoim hoście, gdzie obszar roboczy i silnik znajdują się pod określoną ścieżką, zgodnie z wymaganiami środowiska uruchomieniowego SSH w Studio. Ekran CI/CD nie generuje tego zadania; oto opcje używane przez środowisko uruchomieniowe SSH samego Studio:

ssh -o BatchMode=yes -o StrictHostKeyChecking=yes -o ConnectTimeout=8 <user>@<host> "cd <path> && node bin/nexus.js ci --all"
scp -r -o BatchMode=yes -o StrictHostKeyChecking=yes <user>@<host>:<path>/evidence ./evidence

• Tylko uwierzytelnianie kluczem. BatchMode=yes nigdy nie pyta o hasło. Zapisz klucz prywatny z sekretu CI w pliku, który może odczytać tylko zadanie, i usuń go po zakończeniu zadania.
• StrictHostKeyChecking=yes. Klucz hosta musi już znajdować się w pliku known_hosts środowiska wykonawczego: przechowuj wiersz z kluczem publicznym hosta w zmiennej CI i zapisz go w tym pliku przed pierwszym wywołaniem ssh. Nigdy nie ustawiaj wartości no.
• Kod zakończenia jest zwracany. ssh kończy działanie z kodem zdalnego polecenia, więc krok kończy się niepowodzeniem, gdy zestaw testów nie przejdzie, a scp pobiera materiały dowodowe, w tym JUnit XML, na potrzeby kroku zapisywania artefaktów.
• Host sprawdza własną licencję i jest liczony jako jedna maszyna w Twoim planie.

Sekrety

• Przechowuj tokeny, adresy URL webhooków i klucze prywatne SSH jako sekrety CI: w GitHub w Settings, Secrets and variables, Actions lub za pomocą gh secret set <KEY>; w GitLab jako maskowane zmienne w Settings, CI/CD, Variables. Nigdy w repozytorium, pliku potoku ani dzienniku.
• Wygenerowany przepływ pracy GitHub odczytuje tylko klucze integracji z secrets.<KEY> i tylko w krokach Nexus: TELEGRAM_*, SLACK_ENABLED, SLACK_WEBHOOK_URL, JIRA_* i przełączniki powiadomień. Ekran CI/CD podaje dla każdego z nich polecenie gh secret set; gh pyta o wartość, a nic nie jest wyświetlane.
• Klucza licencyjnego nie należy umieszczać w CI. Aktywuj trwałe środowisko wykonawcze raz, ręcznie: klucz jest wysyłany jednorazowo i nie jest przechowywany. Jeśli Twój proces mimo to wymaga klucza w systemie CI, przechowuj go wyłącznie jako maskowany sekret; żaden element wygenerowanego potoku go nie odczytuje.
• Nigdy nie wypisuj sekretu w kroku. Silnik usuwa sekrety z tekstu zapisywanego jako materiał dowodowy, takiego jak komunikaty o niepowodzeniach JUnit i dzienniki; nie usuwa ich z danych wyjściowych konsoli samego zadania, a usługa CI maskuje tylko wartości zapisane jako sekrety.

JUnit XML i materiały dowodowe jako artefakty

• GitHub przesyła evidence/ jako nexus-evidence, a przy użyciu macierzy osobny nexus-evidence-<browser> dla każdej przeglądarki, niezależnie od tego, czy uruchomienie zakończyło się powodzeniem czy niepowodzeniem. Plik JUnit XML znajduje się wewnątrz, w evidence/ci/junit.xml.
• GitLab zachowuje evidence/ i udostępnia evidence/ci/junit.xml jako raport JUnit, dzięki czemu nieudane testy są widoczne w żądaniu scalenia.
• W Studio ekran CI/CD umożliwia uruchomienie przepływu pracy GitHub i pobranie jego materiałów dowodowych do evidence/ci-remote/run-<id> w obszarze roboczym.
• Gdzie znajduje się kopia. Artefakt to kopia materiałów dowodowych, w tym zrzutów ekranu i dzienników, przechowywana w usłudze CI; w przypadku usługi hostowanej jest to sprzęt należący do kogoś innego. Ustaw okres przechowywania artefaktów zgodny ze swoją polityką lub zachowaj materiały dowodowe w swoim środowisku wykonawczym i przesyłaj tylko evidence/ci/junit.xml.

Rozwiązywanie problemów

SEAT_LIMIT w środowisku wykonawczym hostowanym w chmurze lub tymczasowym

Każda nowa maszyna wirtualna jest dla licencji nową maszyną, więc tymczasowe środowisko wykonawcze wymagałoby aktywacji dla każdego zadania. Gdy wszystkie maszyny w Twoim planie są aktywne, aktywacja jest odrzucana z błędem SEAT_LIMIT: “Wszystkie maszyny w Twoim planie są w użyciu. Dezaktywuj jedną na swoim koncie.” Użyj trwałego środowiska wykonawczego na własnym hoście (opcja A lub B) i dezaktywuj maszyny, których już nie używasz, w sekcji Licencja i maszyny na swoim koncie (więcej o SEAT_LIMIT).

Środowisko wykonawcze było offline przez kilka dni

Licencja komputera musi być weryfikowana co najmniej raz na 7 dni. Potem przez kolejne 4 dni wyświetlane jest powiadomienie, a następnie włączany jest tryb tylko do odczytu: zestawy testów nie są uruchamiane do czasu pomyślnej weryfikacji, a materiały dowodowe pozostają dostępne do odczytu. Gdy komputer wykonawczy odzyska połączenie, nexus license renew ponawia weryfikację (praca bez połączenia).

„brak /etc/machine-id” w kontenerze

Kontener nie ma identyfikatora komputera, który można odczytać na potrzeby licencji. Zamontuj identyfikator hosta: -v /etc/machine-id:/etc/machine-id:ro, lub dodaj ten sam wiersz w sekcji volumes: pliku compose.

Zadanie kończy się kodem 2

Nic nie zostało uruchomione: żaden test nie pasował do identyfikatorów lub polecenie było nieprawidłowe. Sprawdź identyfikatory przekazane do nexus ci, w tc_ids na GitHub lub TC_IDS na GitLab.

Weryfikacja klucza hosta nie powiodła się

Ustawienie StrictHostKeyChecking=yes spowodowało odrzucenie hosta, którego nie ma w known_hosts lub którego klucz uległ zmianie. Dodaj klucz hosta z zaufanego źródła, po sprawdzeniu jego odcisku bezpośrednio na hoście. Nie wyłączaj weryfikacji.