Обзор
Чтобы создать надёжное расширение для Discourse, разумно включить непрерывную интеграцию (CI) в ваш плагин или компонент темы. Это поможет выявлять ошибки на ранней стадии и снизить вероятность появления багов в вашем коде.
Настройка рабочего процесса CI с использованием GitHub Actions для автоматизации сборки и тестирования — это подход, который команда Discourse использует во всех наших компонентах, и мы рекомендуем вам сделать то же самое.
Настройка
Чтобы добавить автоматизированные рабочие процессы GitHub Actions для обнаружения ошибок, вам нужно создать папку .github/workflows в корневом каталоге вашего репозитория.
Внутри папки workflows вы можете определить набор автоматизаций, которые должны запускаться GitHub Actions. Например, это могут быть файлы .yml для линтинга и тестов.
Мы создали шаблоны рабочих процессов как для плагинов, так и для компонентов тем, которые вы можете использовать. Они подключаются к нашим определениям «переиспользуемых рабочих процессов» здесь.
В репозитории-шаблоне на GitHub вы можете нажать кнопку Use this template (Использовать этот шаблон), чтобы создать репозиторий плагина/компонента темы на основе шаблона.
Альтернативно, если у вас уже есть проект, к которому вы хотите добавить рабочие процессы, просто скопируйте соответствующий рабочий процесс в папку .github/workflows/ вашего репозитория:
Плагины: discourse-plugin.yml
Темы и компоненты тем: discourse-theme.yml
Эти шаблоны привязаны к конкретной основной версии наших переиспользуемых рабочих процессов. Небольшие улучшения, которые мы вносим в рабочие процессы, будут автоматически применяться в вашей теме/плагине. Для разрушающих изменений (например, введения нового линтера) мы будем повышать основную версию переиспользуемых рабочих процессов, и вам потребуется обновить свой рабочий процесс, чтобы он указывал на новую версию.
Готово! Всё настроено! Просто создайте коммит или PR в вашем репозитории, и GitHub Actions автоматически обнаружит рабочие процессы и начнёт запускать задачи.
GitHub Actions покажет разбор каждого теста, а после выполнения укажет 
или 
в зависимости от того, прошёл тест или нет.
Если тест не прошёл, нажатие на детали даст вам некоторую информацию о том, что именно не сработало, что может подсказать, что не так с вашим кодом и что нужно исправить.
Добавьте свои тесты
Чтобы тесты плагинов и компонентов работали эффективно, важно, чтобы вы писали тесты для своего плагина или компонента темы.
Подробнее о том, как писать фронтенд-тесты с использованием EmberJS, см.:
- Write acceptance tests and component tests for Ember code in Discourse
- Introduction - Testing - Ember Guides
Подробнее о написании тестов RSpec с использованием Rails см.:
Примеры
В вашем интересе мы отобрали несколько примеров плагинов и компонентов тем, в которых интегрировано надёжное тестирование:
| Плагин / Компонент | Клиентские тесты | Серверные тесты |
|---|---|---|
| Assign |  Посмотреть папку |
Посмотреть папку |
| Calendar | Посмотреть папку |
Посмотреть папку |
| Reactions | Посмотреть папку |
Посмотреть папку |
| Right Sidebar Blocks | Посмотреть папку |
|
| Tag Icons | Посмотреть папку |
|
| Table Builder | Посмотреть папку |
Этот документ находится под контролем версий — предложите изменения на github.