时间戳

首页 > 解决方案 > 如何为 CI 组织两个 git repos

git - 如何为 CI 组织两个 git repos

问题描述

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

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

我们如何组织我们的持续集成？

PS 我们也不想在版本中使用标签，因为人们并行工作，并且很难保持始终不递减的版本。

标签： gitgomodulecontinuous-integration

解决方案

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

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

（该go命令通常知道如何将分支名称解析为特定的提交，因此您不需要明确命名提交哈希。但是，该go.mod文件将记录具有解析哈希的伪版本。）

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

话虽如此，听起来您切换到 monorepo 可能会更简单，也许go.mod在 repo 根目录下有一个文件，以便所有内容都同步进行版本控制。根据我的经验，避免 Go 项目变成单体的最好方法是使用internal包，而不是单独的存储库。

推荐阅读