Zmiana rozdzielczości działania Xvfb na Travis CI

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:


before_install:
#
-sudo service xvfb stop
-sudo sed -i 's/1024×768/1280×1024/g' /etc/systemd/system/xvfb.service
-sudo service xvfb start
#

view raw

.travis.yml

hosted with ❤ by GitHub

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.

  1. 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.
  2. 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 prefix travis_run_ i powinny wykonać się wszystkie polecenia z tej sekcji.
  3. 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 Bashu set +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.
  4. 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ść.
  5. 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:


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

view raw

.travis.yml

hosted with ❤ by GitHub

Skomentuj

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Wyloguj /  Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Wyloguj /  Zmień )

Zdjęcie na Facebooku

Komentujesz korzystając z konta Facebook. Wyloguj /  Zmień )

Połączenie z %s

Ta witryna wykorzystuje usługę Akismet aby zredukować ilość spamu. Dowiedz się w jaki sposób dane w twoich komentarzach są przetwarzane.