He estado jugando con esto y he encontrado una solución en Github.
Así que una simple marca verde para el trabajo de CI más reciente no es suficiente, ya que las cosas podrían haber cambiado recientemente, lo que podría romper el plugin. Básicamente, necesitas volver a ejecutar los trabajos de CI cuando Discourse actualiza las ramas.
En este repositorio de ejemplo desarrollé una solución eficiente. Es básicamente un flujo de trabajo programado que comprueba las ramas importantes del repositorio de Discourse para ver si hay cambios; si los hay, activará el flujo de trabajo normal de CI que debería ejecutar la suite de pruebas. En tu readme, puedes colocar algunas insignias para mostrar cómo se ejecutaron los flujos de trabajo de CI contra los cambios más recientes.
El flujo de trabajo de monitoreo se ejecuta en segundos. Por lo tanto, cuando se programa, solo consumiría 1 minuto de tiempo de acción de Github.
Obviamente, la fiabilidad de toda esta configuración depende del esfuerzo del desarrollador del plugin/componente temático para crear una buena suite de pruebas.
Y todavía tienes el problema de la experiencia de usuario de que, desde la página de “actualización” de Discourse, no sabes si el trabajo de CI más reciente falló para una versión específica.
Por lo tanto, además de tener un flujo de trabajo de monitoreo que reconstruye un plugin cuando la rama de Discourse cambia, necesitas crear un artefacto de compilación que registre el resultado (éxito/fallo). En los metadatos de tu plugin, deberías poder apuntar a este artefacto, y Discourse debería recuperar este artefacto para mostrar la compatibilidad/resultado en la interfaz de actualización.
No es una construcción infalible, pero es algo.