Ich habe damit herumgespielt und eine Lösung in Github gefunden.
Ein einfaches grünes Häkchen für den letzten CI-Job reicht also nicht aus, da sich Dinge kürzlich geändert haben könnten, die das Plugin brechen könnten. Grundsätzlich müssen Sie die CI-Jobs erneut ausführen, wenn Discourse Branches aktualisiert.
In diesem Beispiel-Repository habe ich eine effiziente Lösung ausgearbeitet. Es handelt sich im Grunde um einen geplanten Workflow, der die wichtigen Branches des Discourse-Repositorys überprüft, um zu sehen, ob es Änderungen gibt. Wenn es welche gibt, löst er den normalen CI-Workflow aus, der die Testsuite ausführen sollte. In Ihrer Readme können Sie dann einige Badges platzieren, um zu zeigen, wie CI-Workflows gegen die neuesten Änderungen ausgeführt wurden.
Der Überwachungs-Workflow läuft in Sekunden. Wenn er geplant ist, verbraucht er nur 1 Minute GitHub-Action-Zeit.
Offensichtlich hängt die Zuverlässigkeit des gesamten Setups von der Anstrengung des Plugin-/Theme-Component-Entwicklers ab, eine gute Testsuite zu erstellen.
Und Sie haben immer noch das UX-Problem, dass Sie auf der “Update”-Seite von Discourse nicht wissen, ob der letzte CI-Job für eine bestimmte Version fehlgeschlagen ist.
Neben einem Überwachungs-Workflow, der ein Plugin neu erstellt, wenn sich der Discourse-Branch ändert, müssen Sie ein Build-Artefakt erstellen, das das Ergebnis (Pass/Fail) aufzeichnet. In Ihren Plugin-Metadaten sollten Sie auf dieses Artefakt verweisen können, und Discourse sollte dieses Artefakt abrufen, um die Kompatibilität/das Ergebnis in der Update-Oberfläche anzuzeigen.
Es ist keine narrensichere Konstruktion, aber es ist etwas.