Я поэкспериментировал с этим и нашёл решение в GitHub.
Просто зелёной галочки для самой последней задачи CI недостаточно, так как за последнее время могли произойти изменения, которые могут нарушить работу плагина. По сути, вам нужно перезапускать задачи CI при обновлении веток Discourse.
В этом примере репозитория я разработал эффективное решение. По сути, это запланированный рабочий процесс, который проверяет важные ветки репозитория Discourse на наличие изменений. Если изменения обнаружены, запускается обычный рабочий процесс CI, который должен выполнить набор тестов. В вашем README вы можете разместить бейджи, чтобы показать, как работали рабочие процессы CI по отношению к последним изменениям.
Рабочий процесс мониторинга выполняется за секунды. Поэтому при планировании он потребляет всего одну минуту времени действий GitHub.
Очевидно, что надёжность всей этой конструкции зависит от усилий разработчика плагина/темы-компонента по созданию качественного набора тестов.
И у вас всё ещё остаётся проблема UX: на странице «Обновление» в Discourse вы не знаете, не провалилась ли самая последняя задача CI для конкретной версии.
Поэтому, помимо наличия рабочего процесса мониторинга, который пересобирает плагин при изменении ветки Discourse, вам нужно создавать артефакт сборки, фиксирующий результат (успех/неудача). В метаданных вашего плагина вы должны иметь возможность указать на этот артефакт, и Discourse должен извлекать его, чтобы отображать информацию о совместимости/результате в интерфейсе обновлений.
Это не безупречная конструкция, но это уже что-то.