git-bisect，但对于 N 个 repos答案

【问题标题】：git-bisect, but for N reposgit-bisect，但对于 N 个 repos
【发布时间】：2017-04-24 17:25:25
【问题描述】：

我们的软件是模块化的，我在一个项目中有大约 20 个 git 存储库。

如果测试失败，有时很难找到匹配的提交，因为有几个开发人员在这 20 个存储库上工作。

我知道测试昨天成功了，今天失败了。

有时我使用 git-bisec，但这仅适用于一个 git repo。

两个 git repos 中的更改通常会导致测试失败。

我可以自己编写一个循环遍历我的 N 个 git 存储库的脏脚本，但在这样做之前，我想知道专家将如何解决这个问题。

我使用 Python、Django 和 pytest，但 AFAIK 这对于这个问题并不重要。

【问题讨论】：

stackoverflow.com/questions/9711592/…的可能重复
@Phillip 的链接看起来很黄金，但我只想说“这就是你使用子模块的原因。这几乎是子模块的点：记录哪些提交一起去从多个基础构建一个项目”。如果您使用了子模块，那么 bisect 将完美运行。”。
尝试手动缩小搜索范围：找到复杂应用程序正常的时刻，然后它就坏了。是否可以在一行中列出整个提交列表并进行思考？
@jthill 到目前为止，我们不使用 git 子模块。我认为没有他们也可以解决问题。也许有点难，但并非不可能。
@jthill 我同意子模块是个好主意，但我认为我无法说服其他任何人，而且大到需要它们的项目通常也大到足以拥有多个开发人员。

【解决方案1】：

我个人更喜欢使用repo tool 来管理复杂的项目。将这 20 个存储库放在 manifest.xml 中，每次构建开始时创建补丁清单，如果构建失败，请执行 repo diff manifests 以查看更改的内容和位置。

【讨论】：

【解决方案2】：

有用于“反向依赖”CI 构建的 QA 工具类别。因此，每次进行较低级别的更改时，都会重新构建您的较高级别的项目。在规模上，它可能是资源密集型的。

如果您停止处理 repo-to-repo 关系并开始遵循子组件的版本发布方法，则整个问题都会被删除。然后，您可以跟踪较低级别依赖项的版本，并知道何时升级它已损坏。如果您想将 CI 系统化，您的 CI 可以针对多个版本的依赖项进行构建。

Git 子模块完成对单个提交的跟踪，因此您可以再次决定何时合并较低级别的更改。（值得注意的是，如果您只更新到标记的发布提交，它也可以像发布版本一样使用。）

【讨论】：

您使用此类 QA 工具中的哪个工具用于“反向依赖”CI 构建？
我现在的商店之前在我们的旧 CI 服务器上使用 Jenkins 脚本完成了这项工作。
我们已经在使用 Jenkins。它从我们那里提取 N 个 repos（全部来自 master（敏捷））并尝试测试特定的项目。一个项目很小，主要是配置，只有几行代码。你现在用什么工具？
我们切换到 Travis CI，发布更正式的 SemVer。