如何设置 CI 以同时使用两个 git 存储库

最近发现不少小伙伴都对Golang很感兴趣，所以今天继续给大家介绍Golang相关的知识，本文《如何设置 CI 以同时使用两个 git 存储库》主要内容涉及到等等知识点，希望能帮到你！当然如果阅读本文时存在不同想法，可以在评论中表达，但是请勿使用过激的措辞~

我有一个 git repo“core”和“project”repo，它使用“core”作为依赖项。如果我想更改“核心”模块的某些 API 及其在“项目”中的用法，我会在 gitlab 中创建两个单独的拉取请求。但是，如果“核心”包含 API 更改，我们的持续集成系统无法测试“项目”，直到“核心”被合并。 我想要的是“项目”测试将在“核心”中的同一分支上进行的可能性。例如，如果我在“project”和“core”中创建了分支“feature-42”，则“project”测试将从“core”的“feature-42”分支开始。

现在我们有机会移动 go 模块，但是很难总是在 go.mod 文件中指定直接提交哈希（很可能会犯错误）。 看起来我们应该使用 monorepo，但我担心我们的项目可能会成为整体（考虑到我们没有非常合格的开发人员）。

我们如何组织持续集成？

附注另外，我们不想使用带有版本的标签，因为人们并行工作，并且很难维护始终不减少的版本。

解决方案

您的 go.mod 文件可以指定依赖项的显式提交 - 即使该提交位于分支上！ - 只要提交实际上已发布到该存储库。

因此，如果您在 feature-42 分支上发布了 core 的功能，并希望在 project 中使用该功能，则可以在 project 模块内运行 go get core@feature-42 ，您应该会获得包含该功能的版本。

（go 命令通常知道如何将分支名称解析为特定提交，因此您不需要显式命名提交哈希。但是，go.mod 文件将记录包含已解析哈希的 pseudo-version。 ）

作为另一种选择，您可以将 go mod edit -replace 命令添加到 CI 系统中，以使其显式地将所选版本的 core 模块替换为相关分支。

综上所述，听起来您切换到单一存储库可能会更简单，也许在存储库根目录下使用单个 go.mod 文件，以便所有内容都以锁定步骤进行版本控制。根据我的经验，避免 Go 项目变成庞然大物的最佳方法是使用 internal packages，而不是单独的存储库。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《如何设置 CI 以同时使用两个 git 存储库》文章吧，也可关注golang学习网公众号了解相关技术文章。