Автоматизация тестирования epm play и новых версий приложений на различных дистрибутивах (Иван Мажукин, OSSDEVCONF-2025) — различия между версиями

Текущая версия на 16:37, 29 января 2026

Докладчик: Иван Мажукин

Рассматривается опыт автоматизации тестирования epm play для установки сторонних приложений на различных системах. Ранее тестирование выполнялось на выделенной виртуальной машине, что ограничивало охват и снижало надёжность.
Переход на GitLab CI с использованием GitLab Runner в Kubernetes позволил запускать тесты в изолированных контейнерах разных дистрибутивов и оперативно выявлять проблемы скачивания, перепаковки и установки пакетов.
В качестве примера демонстрируется организация проверки на базе ALT p11.

Видео[править вики-текст]

on youtube

Презентация[править вики-текст]

Thesis[править | править вики-текст]

Ключевые слова: epm play, GitLab CI, Kubernetes, автоматизация тестирования.

Аннотация[править | править вики-текст]

Рассматривается опыт автоматизации тестирования epm play для установки сторонних приложений на различных системах. Ранее тестирование выполнялось на выделенной виртуальной машине, что ограничивало охват и снижало надёжность. Переход на GitLab CI с использованием GitLab Runner в Kubernetes позволил запускать тесты в изолированных контейнерах разных дистрибутивов и оперативно выявлять проблемы скачивания, перепаковки и установки пакетов. В качестве примера демонстрируется организация проверки на базе ALT p11.

В работе рассматривается опыт автоматизации тестирования установки сторонних приложений через epm play. Данный механизм позволяет пользователям Linux-дистрибутивов запускать установку пакетов из разных источников (AppImage, tar.gz, deb, snap и др.) и перепаковывать их в «родной» пакет дистрибутива. Ключевая проблема заключалась в проверке корректности работы этих пакетов: при обновлении или добавлении нового приложения необходимо убедиться, что оно скачивается, распаковывается и устанавливается без ошибок.

Исходная схема проверки строилась на выделенной виртуальной машине, где по расписанию запускался скрипт, последовательно выполнявший установку приложений из epm. Он проходил по списку приложений, выполнял epm play, фиксировал результат и сохранял информацию о версии в каталогах epm-play-versions, epm-errors, epm-logs и epm-requires. Данные затем синхронизировались с FTP-сервером. Ограничения такого подхода:

одновременный запуск только одного теста;
постепенное «засорение» системы из-за многочисленных установок и удалений;
отсутствие изоляции и зависимость от состояния конкретной машины.

Новая схема реализована с использованием GitLab CI и GitLab Runner, работающего в Kubernetes. Для каждого приложения формируется отдельная job, выполняющаяся в изолированном контейнере. Список приложений автоматически генерируется скриптом gen-ci.sh, который вызывает epmp --short и формирует файл .gitlab-ci.yml с десятками задач.

Таким образом, каждая задача полностью изолирована, что делает возможным параллельное тестирование. Ограничение одновременного числа job осуществляется настройками concurrent в конфигурации Runner или параметрами Kubernetes.

Организация тестов[править | править вики-текст]

Организация тестов построена так, что проверка выполняется как по расписанию, охватывая весь набор приложений, так и при изменениях в скриптах каталогов play.d/, pack.d/ или repack.d/, когда запускаются только соответствующие задания. При успешной установке приложения новая рабочая версия автоматически фиксируется в каталоге epm-play-versions, а при возникновении ошибки актуальной остаётся предыдущая версия. Все результаты — версии, ошибки, логи и зависимости — сохраняются как артефакты GitLab CI и могут быть автоматически собраны внешними скриптами для последующей публикации.

Особенности реализации[править | править вики-текст]

Техническая реализация основана на запуске контейнеров на базе различных образов, например alt:p11 и alt:sisyphus, что позволяет проверять установку сразу в нескольких дистрибутивах. Для работы с IPFS применяются переменные окружения EGET_IPFS_FORCE_LOAD=1, EPM_IPFS_DB_UPDATE_SKIPPING=1 и другие, обеспечивающие корректность загрузки и обновления данных. Для устойчивости пайплайнов каталоги артефактов создаются заранее, а в них помещаются «якорные» файлы .keep, предотвращающие завершение GitLab CI с ошибкой при отсутствии данных. Секреты (токены и пароли) вынесены в переменные GitLab и не выводятся в логах.

Результаты внедрения[править | править вики-текст]

Внедрение новой системы сделало тестирование полностью воспроизводимым и изолированным. Появилась возможность параллельной проверки десятков приложений, где ограничения определяются только доступными ресурсами кластера. Время реакции на новые коммиты существенно сократилось: ошибки выявляются сразу при интеграции изменений. Кроме того, перенос результатов стал проще — теперь они доступны через артефакты GitLab CI, а не только через FTP, что упростило последующую обработку и публикацию.

Литература[править | править вики-текст]

GitLab Documentation. «GitLab CI/CD pipelines». https://docs.gitlab.com/ee/ci/
GitLab Documentation. «Install GitLab Runner using the Helm Chart». https://docs.gitlab.com/runner/install/kubernetes.html
Helm Documentation. «Helm — The Kubernetes Package Manager». https://helm.sh/docs/
Разработанные скрипты автоматизации CI (лицензия AGPL-3.0). https://gitlab.eterfund.ru/vanomj/eepm/tree/devel

Примечания и ссылки[править вики-текст]

Проект EPM, https://github.com/Etersoft/eepm/