我邀请您分享关于可能的 CI 工作流的想法，这些工作流将在社区提供的非官方插件上运行测试。
一些社区严重依赖插件，但没有建立维护：
由于测试插件依赖于 Discourse 安装作为测试平台，我想知道社区支持的 CI 工作流可能是什么样的。
一些插件包含规范，例如 @angus 实现的 activitypub，据我所知，这使得 CI 可以进行测试。
目前，我正在考虑两种改进非官方插件测试的方法，具体取决于插件源代码中包含的规范/测试：
a) 构建一些机制，帮助站点维护者在暂存环境中运行测试
b) 提供一项服务，该服务可以分叉预定义的测试映像，以报告在插件的最后发布代码上运行的测试。
您怎么看？
我是否错过了任何已建立的工作流？
这可能很有用：
是的，补充一下 @angus 分享的内容，您可以在此处找到我们的每日兼容性仪表板：
https://coop.pavilion.tech/plugins?branch=tests-passed
该仪表板显示了 Pavilion 插件（有时也包括其他插件）针对 tests-passed 和 stable 的检查状态。它每天自动更新。
这当然依赖于测试，包括冒烟测试、specs（后端）和 qunit（前端）测试。
我们的订阅插件（Custom Wizard）拥有最多的测试覆盖率，正如您所料，但我们的一些免费插件也包含一套不错的后端和前端测试（例如 Locations）。
编写测试是一种良好的实践，随着我们公司业务的成熟，Pavilion 在这方面的纪律性也越来越强。
最关键的是，测试还能记录您预期的功能，这在兼容性更新或重构期间尤为重要。
令人印象深刻。您能否指出实现此功能的代码？
这是根据 @angus 的图表设计的架构，涉及多个仓库，但这是状态服务器：
这也是一种方法：
这样你的覆盖率就会随着时间的推移而建立起来……
此外：
所有官方插件都有可供参考的规范。discourse-plugin-Skelton 插件包含 github Actions，可在每次提交时运行测试，而且我认为是每天运行一次。
我理解正确吗？
a) 这可以通过 GitHub Actions 获得：具有适当规范/使用 GitHub Actions 进行测试的插件将在 GitHub 上显示徽章，如果所有测试都通过，并且 CI 操作的状态可由 API 读取。
b) 除了 discourse 官方插件和 pavilion 插件之外，管理员无法自动了解所使用的插件是否将与计划更新的版本兼容？
在搜索关于插件兼容性的元数据时，我通过 .discourse-compatibility 文件找到了 https://meta.discourse.org/t/pinning-plugin-and-theme-versions-for-older-discourse-installs/156971。
据我理解，这是解决反向问题的一种方法：discourse 太旧，无法支持插件。
如何处理另一种情况：插件太旧，无法支持 discourse？
/admin/upgrade 是否可以警告有关插件的信息，这些插件在计划的升级中测试失败？
我们最初的目标是提供一个非品牌化的插件仪表板版本，第三方作者可以在其中提交他们的插件以供包含。但这并没有获得任何关注，部分原因是第三方插件开发者的数量非常少。
第三方的 Discourse 插件开发相当小众，而提供具有良好测试覆盖率的插件的第三方更是非常小众！ 
这个领域中的许多自由职业者要么加入了 Pavilion，要么加入了 CDCK（或者，随着时间的推移，两者都加入了！）。
所以最后我们决定将我们的仪表板合并到我们品牌化的社区网站中。
