O ile uruchamianie „zwykłych” testów w ramach ciągłej integracji (Jenkins, Travis CI, Circle CI) raczej nie jest problematyczne – bo przecież uruchamiamy je tylko przeciwko konkretnym fragmentom kodu – to testy wymagające Xvfb (X virtual framebuffer) już takie oczywiste nie są.
Po zainstalowaniu Xvfb na Travisie powinien być dostępny plik konfiguracyjny tej usługi – /etc/systemd/system/xvfb.service
. Jego zmiana wymagać będzie sudo
.
Warto sprawdzić, jaka rozdzielczość ustawiona jest domyślnie – u mnie było to 1024x768px – co w sumie w czasach obecnych bardziej pokrywa się z urządzeniami mobilnymi i błędnie założyłem, że Travis będzie operował na wyższej rozdzielczości – no bo przecież mamy XXI wiek.
W samych testach, mimo wymuszania maksymalizacji okna otwartej przeglądarki – niektóre testy kończyły się niepowodzeniem. Okazało się, że problemem jest właśnie rozdzielczość ekranu, a nawet zmaksymalizowane okno było na tyle małe, że strona wyświetlana była jak na urządzeniach mobilnych, przez co pewne elementy strony nie były widoczne w ogóle albo wymagały wykonania dodatkowych akcji. Wyjaśnia to też, dlaczego lokalnie testy przechodziły bez zająknięcia.
Niemało stresu kosztowało mnie znalezienie sposobu na wymuszenie, aby xvfb uruchamiał okienka w większej rozdzielczości – gdy już udało się to rozgryźć – okazuje się to wyjątkowo banalne.
Jedyne co trzeba było wykonać, to zatrzymać usługę xvfb, poleceniem – na przykład sed
– zmienić poprzednio ustawioną rozdzielczość na nową w pliku konfiguracyjnym usługi i ponownie uruchomić usługę, czyli:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
before_install: | |
# … | |
-sudo service xvfb stop | |
-sudo sed -i 's/1024×768/1280×1024/g' /etc/systemd/system/xvfb.service | |
-sudo service xvfb start | |
# … |
Dodatkowo, Travis CI pozwala na zbieranie artefaktów ale ograniczeni jesteśmy tylko do wysyłania tego do AWS, a dokładniej do S3 (przynajmniej w chwili obecnej) – debugowanie było z tego powodu mniej przyjemne. Robot Framework, w przypadku niepowodzenia robi zrzuty ekranu – rozdzielczość tych zrzutów ekranu możemy uzyskać poleceniem file selenium-screenshot-1.png
– oczywiście, wymagać to będzie uruchomienia buildu w trybie debugowania i/lub dostępu do utworzonych wcześniej artefaktów.
Przy okazji kilka kolejnych wskazówek, które mogą się przydać w pracy z Travisem.
- Podczas uruchamiania buildu w trybie debugowania otrzymujemy polecenie, którego potrzebujemy, aby zalogować się do Travisa. Warto dodać parametr
-o ConnectTimeout=0
do tego polecenia SSH, jak w poniższym przypadku:
ssh -o ConnectTimeout=0 unique-id-xyz@to2.tmate.io
Oczywiście, potrzebne to jest tylko wtedy, gdy nie mamy tego ustawionego na stałe w konfiguracji SSH.
Po zalogowaniu będziemy mieć możliwość wykonywać polecenia ręcznie – analogicznie do automatycznego wykonywania kolejnych poleceń z pliku.travis.yml
. - Gdy już będziemy zalogowani – aby przyspieszyć pracę i wykonanie poszczegółnych grup poleceń które wiemy, że nie stanowią problemu, możemy korzystać z poleceń basha:
travis_run_*
– czyli travis_run_before_install, travis_run_install, travis_run_before_script, itd – do każdej sekcji z naszego pliku.travis.yml
dodajemy po prostu prefixtravis_run_
i powinny wykonać się wszystkie polecenia z tej sekcji. - Ponieważ Travis w momencie napotkania błędu, przy włączonej – chyba nawet domyślnie – opcji
fast_finish: true
oraz błędów w linii poleceń – zamyka połączenie SSH – sugeruję, by w trakcie debugowania ustawić w Bashuset +e
, zabezpieczy nas to przed przedwczesnym zakończeniem builda z wynikiem błędu (jeśli wpiszemy coś nieprawidłowo w linii poleceń) i będziemy mogli na spokojnie przyjrzeć się komunikatom zwróconym przez wywoływane programy. - Próby ustawiania różnych (wyższych) rozdzielczości dawały dziwne rezultaty:
1280×1024 px -> 1050×888 px
1920×1080 px -> 945×944 px
1680×1050 px -> 825×914 px
czyli jak widać, największą szerokość zrzutu ekranu dała pierwsza rozdzielczość. - Nie ma możliwości komunikacji z Travisem poprzez
scp
– więc próba przesłania artefaktów w ten sposób także się nie powiedzie (uwzględniając kwestie przekazywania agenta SSH).
Cały przykład można znaleźć na GitHub i bezpośrednio na Travisie, a przykładowy plik .travis.yml
poniżej:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dist: xenial | |
notifications: | |
email: false | |
sudo: required | |
language: python | |
python: | |
– "3.7" | |
cache: | |
pip: true | |
addons: | |
apt: | |
packages: | |
– xvfb | |
chrome: stable | |
# https://firefox-source-docs.mozilla.org/testing/geckodriver/geckodriver/Support.html | |
firefox: "57.0" | |
services: | |
– xvfb | |
before_install: | |
– set +e | |
– sudo service xvfb stop | |
– sudo sed -i 's/1024×768/1280×1024/g' /etc/systemd/system/xvfb.service | |
– sudo service xvfb start | |
install: | |
– pip install -r requirements.txt | |
before_script: | |
– python mysite/manage.py migrate | |
# moved hire due to time to run | |
– python mysite/manage.py runserver & | |
# Keep in mind Xenial Chrome Stable version and Chromedriver version | |
– wget http://chromedriver.storage.googleapis.com/74.0.3729.6/chromedriver_linux64.zip | |
– unzip chromedriver_linux64.zip | |
– sudo mv chromedriver /usr/local/bin | |
– sudo chmod a+x /usr/local/bin/chromedriver | |
# Install Firefox (Gecko) driver | |
– wget https://github.com/mozilla/geckodriver/releases/download/v0.24.0/geckodriver-v0.24.0-linux64.tar.gz | |
– tar -xvzf geckodriver-v0.24.0-linux64.tar.gz | |
– sudo mv geckodriver /usr/local/bin | |
– sudo chmod a+x /usr/local/bin/geckodriver | |
script: | |
– robot -d ./results tests/ | |
after_script: | |
– file results/selenium-screenshot-1.png |