Почему мы каждый раз тестируем приложение в восьми средах Linux

В Linux недостаточно сказать, что что-то «работает».

Даже в одной и той же Ubuntu системные библиотеки и инструментарий различаются в зависимости от версии. Способы вывода изображения на экран делятся на X11 и Wayland, а для ввода корейского используются ibus или fcitx5. Если добавить к этому способы установки, количество сочетаний, которые нужно проверить, быстро растёт.

То, что приложение запустилось на одном компьютере разработчика, означает лишь то, что было проверено одно из множества сочетаний.

Поэтому я создал внутри репозитория небольшую лабораторию. Для каждого окружения мы запускаем настоящую виртуальную машину и повторяем одни и те же проверки. Результаты собираем в одной таблице.

Таблица проверяет простые вещи.

Запускается ли приложение. Вводится ли корейский текст.

Мы заранее проживаем первые тридцать секунд, с которыми столкнётся пользователь после установки приложения.

Одно окружение — один файл

Лаборатория использует виртуальные машины KVM вместо контейнеров. Это связано с тем, что в контейнерах трудно корректно воспроизвести настоящую сеансовую среду рабочего стола и демон метода ввода.

Мы загружаем облачный образ дистрибутива и подготавливаем его с помощью cloud-init. Диск создаётся как оверлей поверх исходного образа. Если возникает проблема, его можно удалить и начать заново.

Каждое окружение описывается одним файлом. В файле указаны дистрибутив, образ, сессия, метод ввода и устанавливаемые пакеты. Если нужно проверить новое сочетание, достаточно добавить один файл.

Способ ввода зависит от сессии. В X11 используется xdotool, а в Wayland — ydotool. В Wayland нет списка окон, поэтому приложение запускается в полноэкранном режиме в киоск-композиторе. Благодаря этому ввод каждый раз можно выполнять в одном и том же месте.

Приложение собирается на хосте только один раз. Затем один и тот же бинарный файл копируется во все виртуальные машины.

Если заново собирать его для каждого окружения, в результаты будут вмешиваться разные компиляторы и библиотеки. При сбое станет труднее найти причину. И прежде всего файл, который получает пользователь, должен совпадать с файлом, который проверяет лаборатория.

Виртуальная машина проверяет, а хост записывает

Внутри виртуальной машины проверяются три вещи.

Мы смотрим, запускается ли бинарный файл, появляется ли окно и отображается ли 안녕 после ввода dkssud.

Каждая проверка оставляет одну строку JSON. Хост собирает результаты, сохраняет их в файл и формирует таблицу. Результаты измерений остаются в репозитории, чтобы их можно было сравнить со следующей проверкой.

Способ проверки ввода корейского текста зависит от сборки. В сборке для разработки можно сразу проверить символы, находящиеся в процессе композиции. В настоящей сборке для распространения этой функции нет. Вместо этого мы нажимаем Enter, сохраняем файл, а затем читаем содержимое, записанное на диск.

В ходе этого процесса я понял одну вещь. Метод проверки определялся не способом установки, а типом сборки приложения.

Первая таблица показала две вещи

В Ubuntu 22.04 приложение, собранное с системным инструментарием, не открывалось. Причина заключалась в том, что оно не могло найти символ, присутствующий только в последней версии libadwaita.

С другой стороны, мы впервые подтвердили, что в сочетании Wayland и ibus корейский текст вводится нормально.

На основании этого результата было решено включать один и тот же инструментарий во все способы установки. Нынешняя таблица из восьми строк служит предохранителем, который проверяет, не было ли это решение снова нарушено.

Были и проблемы, проявлявшиеся только в реальном окружении. В отличие от настольной версии Ubuntu, в облачном образе отсутствовали модуль ввода GTK4 и начальный режим ввода. Их приходилось устанавливать отдельно в процессе подготовки окружения.

Модуль ibus должен был соответствовать версии демона, установленного в дистрибутиве. Способы использования инструментов ввода тоже различались между дистрибутивами. Пришлось разделить сценарии проверки в соответствии с окружением.

Чтобы экономить память хоста, одновременно запускаются не более двух виртуальных машин. Виртуальная машина завершается сразу после получения результата.

Все эти проблемы было трудно обнаружить, просто читая код. Один и тот же код давал разные результаты в зависимости от окружения. Поэтому и понадобилась таблица.

Таблица не обещает производительность

В таблице также сохраняются время до появления первого экрана и объём используемой памяти. Но они не используются как показатели производительности.

Виртуальная машина отрисовывает экран программно, без GPU, а измерение проводится только один раз сразу после загрузки. Значения могут меняться при каждом запуске. Критерии производительности определяются по медиане трёх измерений на хосте с настоящим GPU.

В этой таблице нужно смотреть не на миллисекунды, а на галочки.

Окружения, которые не удалось проверить, остаются пустыми. Fedora и Debian, настоящая сессия GNOME и диалоговые окна порталов, такие как выбор файла, пока отсутствуют в таблице.

Мы не заполняем непроверенные ячейки словами «скорее всего, будет работать».

Мы не можем решать, какое окружение выберет пользователь. Всё, что мы можем сделать, — заранее войти в это окружение и попробовать запустить приложение.