Обзор
Для создания надежного расширения для Discourse целесообразно внедрить непрерывную интеграцию (CI) в ваш плагин или компонент темы. Это поможет своевременно выявлять ошибки и снизить вероятность появления багов в вашем коде.
Настройка рабочего процесса непрерывной интеграции с использованием GitHub Actions для автоматизации сборок и тестирования — это подход, который команда Discourse применяет ко всем нашим компонентам, и мы рекомендуем вам поступить так же.
Настройка
Чтобы добавить автоматизированные рабочие процессы для GitHub Actions, необходимо создать папку .github/workflows в корневом каталоге вашего репозитория.
Внутри папки workflows вы можете определить набор автоматизаций, которые должны выполнять GitHub Actions. Например, это могут быть файлы .yml для линтинга и тестирования.
Мы создали шаблоны рабочих процессов как для плагинов, так и для компонентов тем, которые вы можете использовать. Они подключаются к нашим определениям «повторно используемых рабочих процессов» здесь.
В шаблонном репозитории на GitHub вы можете нажать кнопку Использовать этот шаблон, чтобы создать репозиторий плагина или компонента темы на основе шаблона.
Или, если у вас уже есть проект, к которому вы хотите добавить рабочие процессы, просто скопируйте соответствующий рабочий процесс в папку .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.