J’ai joué avec ça et j’ai trouvé une solution sur Github.
Donc, juste un coche vert pour le travail CI le plus récent ne suffit pas, car les choses pourraient avoir changé récemment, ce qui pourrait casser le plugin. Essentiellement, vous devez réexécuter les travaux CI lorsque Discourse met à jour les branches.
Dans cet exemple de dépôt, j’ai trouvé une solution efficace. Il s’agit essentiellement d’un workflow planifié qui vérifie les branches importantes du dépôt Discourse pour voir s’il y a des changements, s’il y en a, il déclenchera le workflow CI normal qui devrait exécuter la suite de tests. Dans votre readme, vous pouvez alors placer des badges pour montrer comment les workflows CI ont fonctionné par rapport aux changements les plus récents.
Le workflow de surveillance s’exécute en quelques secondes. Ainsi, lorsqu’il est planifié, il ne consommerait qu’une minute de temps d’action Github.
Évidemment, la fiabilité de toute cette configuration dépend de l’effort du développeur du plugin/composant de thème pour créer une bonne suite de tests.
Et vous avez toujours le problème d’UX selon lequel, depuis la page “mise à jour” de Discourse, vous ne savez pas si le travail CI le plus récent a échoué pour une version spécifique.
Donc, en plus d’avoir un workflow de surveillance qui reconstruit un plugin lorsque la branche Discourse change, vous devez créer un artefact de build enregistrant le résultat (réussite/échec). Dans les métadonnées de votre plugin, vous devriez être en mesure de pointer vers cet artefact, et Discourse devrait récupérer cet artefact pour afficher la compatibilité/le résultat dans l’interface de mise à jour.
Ce n’est pas une construction infaillible, mais c’est quelque chose.