Testlerinizi CI/CD üzerinden çalıştırın

Studio'nun CI/CD ekranı, GitHub Actions veya GitLab CI için işlem hattı dosyasını oluşturur. Bu kılavuz; dosyanın neleri çalıştırdığını, işin çalışabileceği üç ortamı, gizli bilgileri, oluşturulan JUnit XML dosyasını ve kanıtları, ayrıca CI makinesinde karşılaşılan hataları ele alır.

İşlem hattı dosyası

CI/CD ekranında GitHub Actions veya GitLab CI seçeneğini, tarayıcıları, denetimleri ve işin nerede çalışacağını seçin, ardından dosyayı oluşturun. Studio önce dosyayı yerel olarak doğrular; aynı ekrandan dosyayı depoya kaydedip uzak depoya gönderebilir. Terminalde nexus init --ci github veya nexus init --ci gitlab komutu aynı dosyayı oluşturur.

Birden fazla tarayıcı seçildiğinde GitHub, fail-fast: false ile her tarayıcı için bir iş çalıştırır ve her biri --project=<browser> ekler. Seçtiğiniz denetimler --visual, --a11y, --chaos=, --loop= veya --no-retry ekler.

Çıkış kodları ve JUnit XML

nexus ci, belirttiğiniz testleri (TC1,TC2) veya --all ile tüm testleri çalıştırır; testler başarılı olduğunda 0, başarısızlık durumunda 1, hiçbir test çalışmadığında veya komut hatalı olduğunda 2 koduyla çıkar. JUnit XML dosyasını evidence/ci/junit.xml yoluna yazar; --junit=<path> ile başka bir konuma yazar.

İşin çalışacağı yer: üç seçenek

Her seçenek için etkinleştirilmiş bir makine gerekir: motor, etkinleştirilmemiş makinelerde test paketlerini çalıştırmaz ve etkinleştirilen her makine planınızdaki makine sınırına dahil edilir (planlar ve makineler). Bulutta barındırılan bir çalıştırıcı, runs-on: ubuntu-latest, her iş için yeni bir sanal makine başlatır; bu nedenle etkinleştirmeyi koruyamaz; kendinize ait kalıcı bir çalıştırıcı kullanın.

Seçenek A: Studio'nun bulunduğu makinede barındırdığınız bir çalıştırıcı

1. Nexus Studio'nun kurulu ve etkinleştirilmiş olduğu Windows 11 bilgisayarda veya mini bilgisayarda bir çalıştırıcı kaydedin: GitHub'da deponun Ayarlar, Actions, Çalıştırıcılar, Yeni kendi barındırdığınız çalıştırıcı bölümünden; GitLab'da Ayarlar, CI/CD, Çalıştırıcılar bölümünden.
2. CI/CD ekranında Makinem seçeneğini seçin. Dosyada artık GitHub için runs-on: [self-hosted] veya GitLab için tags: [self-hosted] yer alır.
3. Çalıştırıcıyı, Studio'yu etkinleştiren Windows kullanıcısı olarak çalıştırın. Motor, etkinleştirme bilgisini bu kullanıcının profilindeki .sentinel-studio\license.json dosyasından okur; bu nedenle başka bir hesap altında çalışan çalıştırıcı hizmeti bu bilgiyi bulamaz.

İş, bu makinenin etkinleştirmesini kullanır: makine başına bir etkinleştirme kullanılır, bu etkinleştirme planınızda zaten sayılır ve işlem hattında anahtar bulunmaz. Studio'nun uyarısında belirtildiği gibi, kendi barındırdığınız çalıştırıcıyı yalnızca özel bir depoyla kullanın: herkese açık bir depoda, çekme isteği açan herkes makinenizde kod çalıştırabilir.

Seçenek B: VPS üzerinde, kapsayıcı içinde bir çalıştırıcı

Ubuntu 24.04 LTS x86_64, Docker Engine ve Compose v2 içeren, SSH anahtarıyla kimlik doğrulaması kullanılarak erişilen bir VPS. Planınızda bir makine olarak sayılır.

1. CI/CD ekranında Makinem + Docker seçeneğini seçin. Studio, işlem hattı dosyasının yanı sıra docker-compose.sentinel-runner.yml, Dockerfile.runner ve çalıştırıcının iki giriş noktası betiğini çalışma alanına yazar. Dockerfile.runner, temel olarak mcr.microsoft.com/playwright:v1.62.1-noble kullanır.
2. Ekranda gösterilen komutlar, Studio'nun kendi terminaline değil, VPS üzerindeki bir SSH oturumuna yapıştırılmalıdır. GitHub için 1 saat geçerli bir kayıt belirteci alır ve REPO_URL, RUNNER_TOKEN ve RUNNER_NAME değişkenlerini; GitLab içinse GITLAB_URL ve GITLAB_RUNNER_TOKEN değişkenlerini ayarlar. Ardından:

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

İlk satır GitHub, ikinci satır GitLab içindir. Linux kapsayıcısı içinde lisans, makineyi /etc/machine-id ile tanımlar: ana makinenin bu dosyasını salt okunur olarak bağlayın, /etc/machine-id:/etc/machine-id:ro ve çalıştırıcının ev dizinindeki .sentinel-studio klasörünü bir birimde tutun; böylece yeniden derleme sonrasında etkinleştirme korunur. nexus license activate komutunu ve anahtarınızı kullanarak bir kez elle etkinleştirin, bunu asla işlem hattı dosyasından yapmayın.

Şu anda çalıştırıcı imajı, VPS üzerinde Dockerfile.runner kullanılarak derlenir. Deponun henüz bir kapsayıcı kayıt defteri yok: Studio'nun VPS çalışma ortamında çalıştırdığı, GitHub Container Registry üzerinde yayımlanmış imaj bir sonraki sürümle sunulacak.

Seçenek C: CI işi, SSH üzerinden bir ana makinede çalıştırma başlatır

İş, hangi çalıştırıcıda olursa olsun küçük kalır; test paketleri ise Studio'nun SSH çalışma ortamının beklediği gibi, çalışma alanı ve motorun belirli bir yolda bulunduğu, size ait bir ana makinede çalışır. CI/CD ekranı bu işi oluşturmaz; bunlar Studio'nun kendi SSH çalışma ortamının kullandığı seçeneklerdir:

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

• Yalnızca anahtarla kimlik doğrulama. BatchMode=yes hiçbir zaman parola istemez. CI gizli değeri olarak saklanan özel anahtarı yalnızca işin okuyabileceği bir dosyaya yazın ve iş bittiğinde silin.
• StrictHostKeyChecking=yes. Ana makinenin anahtarı, çalıştırıcının known_hosts dosyasında önceden bulunmalıdır: ana makinenin açık anahtar satırını bir CI değişkeninde saklayın ve ilk ssh çağrısından önce bu dosyaya yazın. Bu ayarı asla no yapmayın.
• Çıkış kodu geri döner. ssh, uzak komutun koduyla sonlanır; böylece test paketi başarısız olduğunda adım da başarısız olur. scp ise JUnit XML dahil kanıtları, çıktı dosyalarını işleyen adım için geri getirir.
• Ana makine kendi lisansını denetler ve planınızdaki makinelerden biri olarak sayılır.

Gizli bilgiler

• Belirteçleri, webhook URL'lerini ve SSH özel anahtarlarını CI gizli değerleri olarak saklayın: GitHub'da Ayarlar, Gizli değerler ve değişkenler, Actions altında veya gh secret set <KEY> ile; GitLab'da ise Ayarlar, CI/CD, Değişkenler altında maskelenmiş değişkenler olarak. Asla depoda, işlem hattı dosyasında veya bir günlükte saklamayın.
• Oluşturulan GitHub iş akışı, secrets.<KEY> üzerinden yalnızca entegrasyon anahtarlarını ve yalnızca Nexus adımlarında okur: TELEGRAM_*, SLACK_ENABLED, SLACK_WEBHOOK_URL, JIRA_* ve bildirim anahtarları. CI/CD ekranı her biri için bir gh secret set komutu listeler; gh değeri sorar ve ekrana hiçbir şey yazdırılmaz.
• Lisans anahtarı CI'da bulunmamalıdır. Kalıcı bir çalıştırıcıyı bir kez elle etkinleştirin: anahtar bir kez gönderilir ve saklanmaz. Süreciniz yine de anahtarın CI sisteminde bulunmasını gerektiriyorsa, onu yalnızca maskelenmiş bir gizli değer olarak saklayın; oluşturulan işlem hattındaki hiçbir şey bu anahtarı okumaz.
• Bir adımda asla gizli bir değeri ekrana yazdırmayın. Motor, JUnit hata iletileri ve günlükler gibi kanıt olarak kaydettiği metinlerden gizli değerleri temizler; işin kendi konsol çıktısını temizlemez ve CI hizmeti yalnızca gizli değer olarak saklanan değerleri maskeler.

Çıktı dosyaları olarak JUnit XML ve kanıtlar

• GitHub, çalıştırma başarılı da olsa başarısız da olsa evidence/ klasörünü nexus-evidence adıyla yükler; matris kullanıldığında her tarayıcı için bir nexus-evidence-<browser> yüklenir. JUnit XML bu klasörün içinde, evidence/ci/junit.xml yolundadır.
• GitLab, evidence/ klasörünü saklar ve evidence/ci/junit.xml dosyasını JUnit raporu olarak sunar; böylece başarısız testler birleştirme isteğinde görünür.
• Studio üzerinden, CI/CD ekranı bir GitHub iş akışı çalıştırması başlatabilir ve kanıtlarını çalışma alanındaki evidence/ci-remote/run-<id> klasörüne indirebilir.
• Kopyanın saklandığı yer. Bir çıktı dosyası, ekran görüntüleri ve günlükler dahil kanıtların CI hizmetinizin depolama alanındaki bir kopyasıdır; barındırılan bir hizmette bu, başkasına ait donanım demektir. Çıktı dosyalarının saklama süresini politikanızın izin verdiği şekilde ayarlayın veya kanıtları çalıştırıcınızda tutup yalnızca evidence/ci/junit.xml dosyasını yükleyin.

Sorun giderme

Bulutta barındırılan veya geçici bir çalıştırıcıda SEAT_LIMIT

Her yeni sanal makine, lisans açısından yeni bir makinedir; bu nedenle geçici bir çalıştırıcı her iş için etkinleştirme gerektirir. Planınızdaki tüm makineler etkin olduğunda, etkinleştirme SEAT_LIMIT ile reddedilir: “Planınızdaki tüm makineler kullanımda. Hesabınızdan birini devre dışı bırakın.” Kendi barındırdığınız kalıcı bir çalıştırıcı kullanın (A veya B seçeneği) ve artık kullanmadığınız makineleri hesabınızdaki Lisans & makineler bölümünden devre dışı bırakın (SEAT_LIMIT hakkında daha fazla bilgi).

Çalıştırıcı günlerdir çevrimdışıydı

Bir makinenin lisansı en az 7 günde bir doğrulanmalıdır. Ardından 4 gün daha uyarı gösterilerek çalışmaya devam eder, sonra salt okunur duruma geçer: kontrol başarılı olana kadar test paketleri çalışmaz, kanıtlar ise okunabilir kalır. Yeniden çevrimiçi olan bir çalıştırıcıda nexus license renew kontrolü tekrar yapar (çevrimdışı çalışma).

Bir kapsayıcıda “/etc/machine-id yok”

Kapsayıcıda lisansın okuyabileceği bir makine kimliği yok. Ana makineninkini bağlayın: -v /etc/machine-id:/etc/machine-id:ro veya aynı satırı compose dosyasında volumes: altına ekleyin.

İş, 2 koduyla sonlanıyor

Hiçbir şey çalışmadı: kimliklerle eşleşen test yoktu veya komut yanlıştı. nexus ci komutuna iletilen kimlikleri, GitHub'da tc_ids veya GitLab'da TC_IDS içinde kontrol edin.

Ana makine anahtarı doğrulanamadı

StrictHostKeyChecking=yes, known_hosts içinde bulunmayan veya anahtarı değişmiş bir ana makineyi reddetti. Anahtarın parmak izini ana makinenin kendisinde kontrol ettikten sonra, ana makinenin anahtarını güvenilir bir kaynaktan ekleyin. Kontrolü kapatmayın.