Tenho brincado com isso e cheguei a uma solução no Github.
Portanto, apenas um tique verde para o trabalho de CI mais recente não é suficiente, pois as coisas podem ter mudado recentemente, o que pode quebrar o plugin. Basicamente, você precisa executar novamente os trabalhos de CI quando o Discourse atualizar os branches.
Neste repositório de exemplo, desenvolvi uma solução eficiente. É basicamente um workflow agendado que verifica os branches importantes do repositório Discourse para ver se há alterações; se houver, ele acionará o workflow normal de CI, que deve executar a suíte de testes. Em seu readme, você pode então colocar alguns badges para mostrar como os workflows de CI foram executados contra as alterações mais recentes.
O workflow de monitoramento é executado em segundos. Portanto, quando agendado, ele consumiria apenas 1 minuto de tempo de ação do Github.
Obviamente, a confiabilidade de toda essa configuração depende do esforço do desenvolvedor do plugin/componente de tema na criação de uma boa suíte de testes.
E você ainda tem o problema de UX de que, na página de “atualização” do Discourse, você não sabe se o trabalho de CI mais recente falhou para uma versão específica.
Portanto, além de ter um workflow de monitoramento que reconstrói um plugin quando o branch do Discourse muda, você precisa criar um artefato de build registrando o resultado (passa/falha). Em seus metadados de plugin, você deve ser capaz de apontar para este artefato, e o Discourse deve recuperar este artefato para exibir a compatibilidade/resultado na interface de atualização.
Não é uma construção à prova de falhas, mas é alguma coisa.