Я приглашаю вас поделиться мыслями о возможных рабочих процессах CI, которые будут запускать тесты для неофициальных плагинов, предоставляемых сообществом.
Некоторые сообщества сильно зависят от плагинов, не имеющих устоявшегося процесса поддержки:
Поскольку тестирование плагинов требует установки Discourse в качестве тестовой среды, я задумался, как может выглядеть рабочий процесс CI, поддерживаемый сообществом.
Некоторые плагины включают спецификации, например реализация @angus для activitypub, которая, насколько я понимаю, позволяет запускать тесты в CI.
В настоящее время я рассматриваю два возможных подхода к улучшению тестирования неофициальных плагинов, в зависимости от наличия спецификаций/тестов в исходном коде плагина:
a) создание механизма, который поможет администраторам сайтов запускать тесты в тестовой среде;
b) создание сервиса, который форкает предварительно определенное тестовое изображение для запуска тестов на последнем опубликованном коде плагина.
В дополнение к CI с тестами бэкенда и фронтенда, которые сейчас есть у большинства плагинов Pavilion, у нас есть система менеджера плагинов, частью которой является CI. Вот как это работает
Она отображает статус проверок на совместимость плагинов Pavilion (а иногда и других) с ветками tests-passed и stable. Эти данные автоматически обновляются каждый день.
Разумеется, это опирается на тесты, включая дымовые тесты, спецификации (бэкенд) и QUnit-тесты (фронтенд).
Наш плагин подписки (Custom Wizard), как можно предположить, имеет самое широкое покрытие тестами, но некоторые из наших бесплатных плагинов также включают хороший набор как бэкенд-, так и фронтенд-тестов (например, Locations).
Написание тестов — это хорошая практика, и, безусловно, по мере взросления нашего бизнеса Pavilion стал ещё более дисциплинированным в этой области.
Критически важно, что тесты также документируют ожидаемую функциональность, что крайне особенно важно при обновлениях совместимости или рефакторинге.
Это архитектура согласно диаграмме от @angus, с участием нескольких репозиториев, но вот сервер статуса:
Это также подход:
Никогда не реализуйте исправление, не проверив наличие теста; если подходящего теста нет, добавьте его.
Желательно сначала разработать тест, показать, что он не проходит, затем исправить проблему и убедиться, что ваш новый тест выполняется успешно.
Таким образом, покрытие тестами будет расти со временем…
Более того:
Добавление тестов постфактум может быть рискованным, так как вы можете неверно истолковать намерения кода… хотя это всё же лучше, чем ничего не делать…
У всех официальных плагинов есть спецификации, которые можно использовать в качестве примеров. Плагин discourse-plugin-Skelton включает GitHub Actions для запуска тестов при каждом коммите, а также, по-видимому, ежедневно.
a) Это доступно через GitHub Actions: плагины с корректными спецификациями и тестами, использующими GitHub Actions, будут иметь значок на GitHub, если все тесты пройдут успешно, а статус действий CI будет доступен через API.
b) За исключением официальных плагинов Discourse и плагинов Pavilion, не существует автоматического обзора для администраторов, будут ли используемые плагины работать в версии, для которой запланировано обновление?
Ища метаданные о совместимости плагинов, я нашел эту тему на основе файла .discourse-compatibility.
Как я понимаю, это решение обратной проблемы: версия Discourse слишком старая для плагина. Как поступить в обратном случае: плагин слишком старый для Discourse?
Могло бы /admin/upgrade предупреждать о плагинах, которые не проходят тесты для планируемого обновления?
Изначально мы создали и предоставили версию панели управления плагинами без брендинга, где авторы сторонних плагинов могли предложить свои плагины для включения. Это не получило широкого распространения, отчасти потому, что сообщество разработчиков сторонних плагинов очень мало.
Создание сторонних плагинов для Discourse — довольно нишевая область, а предоставление сторонних плагинов с хорошим покрытием тестами — очень нишевая задача!
Многие фрилансеры в этой сфере либо присоединились к Pavilion, либо к CDCK (или со временем к обоим!)
В итоге мы решили просто объединить нашу панель управления с нашим брендовым сайтом сообщества.
