TL;DR -大型项目有许多插件，导致自动化测试经常失败。我想把这个项目分成一个核心仓库和一个扩展仓库，但是怎么做呢？
我有一个大型项目（nanoc），其中包含大量插件，每个插件都有自己的依赖项。例如：
- 一个
handlebars插件，取决于therubyracer - 一个 HTML 验证器插件，它调用外部 Web 服务
很多这些插件偶尔会失败：
- 构建失败（例如
therubyracerornokogiri）； - 产生 nanoc 不期望的输出；
- 调用已关闭的 Web 服务（例如 HTML/CSS 验证器）、限制请求等。
nanoc ( Travis ) 使用的持续集成服务非常定期地报告错误。这些错误中有 95% 是由插件引起的。
这使得持续集成测试的结果有些无用。我已经忽略了“错误”构建状态，只是假设插件中出了问题。这显然不是一个好情况。
我想将项目分成两部分：
- 一个核心存储库+gem，包含项目的基本代码，没有插件，以及
- 包含每个插件的插件存储库+gem。
我大部分时间都在核心上工作，偶尔更新插件存储库，使其与核心中完成的工作相匹配（尽管通常核心中的更改不会影响插件）。
这似乎是一种合理的方法，但我有一些保留意见：
- 我不知道如何处理版本控制。是否应该始终对两个 gem 使用相同的版本？这可能与我现在使用的语义版本方法发生冲突。
- 应该有一个插件存储库，还是每个插件都有自己的存储库？这可能会使版本控制更加困难。
- 我想快速发布新插件，这样人们就不必等待新功能发布才能使用新插件。版本控制在这里更加困难。
想法和想法受到赞赏。