# 如何实现非官方插件的CI工作流？

**URL:** <https://meta.discourse.org/t/how-could-a-ci-workflow-for-unofficial-plugins-be-implemented/271774>\
**Category:** Development\
**Created:** [2023 年7 月 16 日 08:02 UTC](https://meta.discourse.org/t/how-could-a-ci-workflow-for-unofficial-plugins-be-implemented/271774 "2023-07-16T08:02:44Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

作者： ![merefield](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/merefield/32/176214_2.png) [@merefield](https://meta.discourse.org/u/merefield)\
发布日期： [2023 年7 月 16 日 08:49 UTC](https://meta.discourse.org/t/how-could-a-ci-workflow-for-unofficial-plugins-be-implemented/271774/6 "2023-07-16T08:49:55Z")

</div>

这是根据 @angus 的图表设计的架构，涉及多个仓库，但这是状态服务器：

> **[GitHub - paviliondev/discourse-plugin-manager: Discourse plugin status server](https://github.com/paviliondev/discourse-plugin-manager)**
>
> Discourse plugin status server

这也是一种方法：

- 永远不要在没有检查测试的情况下实施修复，如果不存在合适的测试，请添加一个。
- 最好先开发测试，证明它失败，然后修复问题并确认你的新测试通过。

这样你的覆盖率就会随着时间的推移而建立起来……

此外：

- 追溯添加测试可能存在风险，因为你可能会误解代码的意图……不过总比什么都不做好……

---

_[View the full topic](https://meta.discourse.org/t/how-could-a-ci-workflow-for-unofficial-plugins-be-implemented/271774)._