Fedora CI
Портал непрерывной интеграции Fedora
Зачем?
Видение
Операционная система состоит из сотен пакетов. Обеспечить их совместную работу как единого целого — непростая задача. Это становится ещё сложнее по мере роста количества пакетов и их взаимозависимостей. Перед выпуском новой версии операционной системы требуется обширное тестирование, чтобы убедиться в её достаточной стабильности. Это осталось в прошлом.
Представьте всегда готовую операционную систему, состоящую из пакетов, которые постоянно поддерживаются в хорошем состоянии. Интегрированную и стабильную благодаря обширному тестовому покрытию, которое непрерывно выполняется при изменениях в отдельных пакетах, позволяя подготавливать новый релиз за гораздо более короткое время или даже мгновенно.
Представьте дистрибутив операционной системы, который вы могли бы выпустить в любой момент. Именно к этому мы стремимся. Здесь на помощь приходит CI, непрерывная интеграция, как бесценный инструмент для обеспечения того, чтобы всё работало вместе как ожидается в любой момент времени.
Манифест
Непрерывная интеграция направлена на то, чтобы сломанные изменения выявлялись как можно скорее и не влияли на других разработчиков, упаковщиков, мейнтейнеров или пользователей. Обратная связь, которую предоставляет непрерывная интеграция, жизненно важна для быстрой гибкой доставки программного обеспечения. Позднее тестирование, спустя долгое время после внесения изменения, не соответствует темпам Fedora. Узнайте цели, терминологию и правила работы CI в манифесте.
Как
Существует три основных элемента, чтобы всё работало как надо: процесс, который чётко определяет, как находить и выполнять тесты; набор инструментов, которые помогают эффективно реализовать этот процесс; и сами тесты.
Процесс
Включение тестов
Тесты можно включить с помощью Спецификации метаданных тестов, реализованной в [Test Management Tool], который предоставляет ряд функций для эффективной работы с тестами.
Контроль
Когда тест падает, CI может предотвратить влияние сломанного изменения на другие пакеты. Этот контроль происходит в Bodhi. Greenwave используется вместе с ResultsDB и WaiverDB для принятия решения о контроле.
Уведомления
Уведомления Fedora были настроены так, чтобы по умолчанию уведомлять каждого упаковщика, когда какой-либо шаг конвейера CI завершается ошибкой в одном из пакетов, которые он поддерживает. Так что если вы мейнтейнер ядра и коммит в репозиторий dist-git ядра не может собрать OSTree, FMN уведомит вас об этом.
Bodhi включает результаты CI на своей странице обновлений, так же как он уже включает результаты тестов из taskotron.
Сообщения
Различные инструменты, участвующие в автоматизации CI, отправляют обновления о ходе тестирования в шину сообщений. Согласованный формат сообщений CI позволяет создавать более простые сервисы, которые будут предоставлять полезные функции для всех.
-
Сообщения Fedora CI … спецификация сообщений CI
-
Datagrepper … поиск отправленных сообщений (например, по теме)
-
fedmsg bus … сообщения, отправляемые конвейером
-
темы … список тем fedmsg, связанных с CI
Инструменты
Инструмент управления тестированием
Инструмент tmt предоставляет удобный способ работы с тестами. Вы можете легко создавать новые тесты, безопасно и просто запускать тесты в разных средах, просматривать результаты тестов, отлаживать код тестов и включать тесты в CI, используя согласованную и лаконичную конфигурацию.
Фреймворки
Поскольку tmt не определяет фреймворк тестирования, который следует использовать, вы можете выбрать наиболее подходящий фреймворк для своего проекта. Вот некоторые примеры:
-
BeakerLib и его Библиотеки
Конвейеры Jenkins
Конвейеры тестирования Jenkins запускают общие тесты для обновлений Bodhi в Testing Farm, собирают и предоставляют результаты.
Packit как CI для dist-git
Packit выступает в роли CI для запросов на включение в dist-git. Результаты тестов отображаются в веб-интерфейсе dist-git. Подробнее см. Packit как Fedora CI.
Тесты
Основой успеха CI являются надёжные тесты хорошего качества, правильно отобранные, стабильные, организованные и постоянно поддерживаемые.
Типы тестов
В целом имеет смысл хранить тесты как можно ближе к upstream. Так какие же типы тестов рекомендуются для тестирования Всегда готовой операционной системы?
-
Тесты базовой функциональности
-
Интеграционные тесты
Для модульных тестов обычно имеет больше смысла хранить их непосредственно в репозитории проекта upstream. Однако в некоторых случаях может быть полезно получать тесты для Fedora CI также из репозитория upstream.
Код тестов
Код тестов может храниться непосредственно в dist-git или загружаться из другого репозитория. Минимальная конфигурация для включения простого дымового теста выглядит так:
execute:
script: foo --version
Тесты из общего репозитория можно включить следующим образом:
discover:
how: fmf
url: https://src.fedoraproject.org/tests/shell
execute:
how: tmt
Подробности и примеры см. в документации Инструмента управления тестированием.
Выполнение тестов
Выполнение тестов так же просто, как запуск одной команды:
tmt run
Узнайте больше в разделе Выполнение тестов.
Общая ответственность
Владение и поддержка тестов должны быть разделены между командами Quality / CI и мейнтейнерами. Для тестов, находящихся в пространстве имён rpm, Quality / CI могут использовать запросы на включение для создания/обновления тестов. Аналогично, в пространстве имён tests как Quality / CI, так и мейнтейнеры должны иметь права на коммиты и просматривать изменения.
Подробнее
Контакты
Если у вас есть вопросы или вы хотели бы принять участие:
-
Matrix: комната #fedora-ci
-
Обсуждение: тег #fedora-ci
-
Заявки: Общие проблемы CI
Ссылки
Вот несколько дополнительных связанных ссылок:
-
Инструмент управления тестированием … документация Fedora CI для tmt
-
Руководство tmt … руководство upstream tmt
-
CI SIG … Группа особых интересов по непрерывной интеграции
Want to help? Learn how to contribute to Fedora Docs ›