如何为 CI 组织两个 git 存储库

Question

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

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

我们如何组织持续集成？

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

Answer 1

您的go.mod文件可以指定依赖项的显式提交 - 即使该提交位于分支上！- 只要提交实际上已发布到该存储库。因此，如果您在feature-42的 分支上发布某个功能core并希望在 中使用该功能project，则可以go get core@feature-42在该project模块中运行，并且您应该获得包含该功能的版本。（该go命令通常知道如何将分支名称解析为特定提交，因此您不需要显式命名提交哈希。但是，该go.mod文件将记录带有解析哈希的伪版本。）作为另一种选择，您可以向 CI 系统添加一个go mod edit -replace命令，让它显式地将所选版本的模块替换core为相关分支。话虽如此，听起来您切换到单一存储库可能会更简单，也许go.mod在存储库根目录下使用单个文件，以便所有内容都以锁定步骤进行版本控制。根据我的经验，避免 Go 项目变成单体的最佳方法是使用internal包，而不是单独的存储库。