该问题源于我们想对 dubbo-go 的 module path 做一次变更,使用 dubbo.apache.org/dubbo-go/v3
替换之前的 github.com/apache/dubbo-go
。
首先,我们做了路径映射,在 dubbo.apache.org 下放置了一个 dubbogo/v3 文件,内容如下:
Redirecting to pkg.go.dev/dubbo.apache.org/dubbo-go/v3...
其次,我们修改了 go.mod 的 module 和对应的所有 import,并修改了所有子模块引用 dubbo-go 使用的 module 路径。
=========================================================================
在做完上述的修改后,我们提 PR 时,发现 CI 失败,经过进一步的日志排查,我们确定是 CI 在跑集成测试时发生了错误,具体的错误提示信息如下:
这一段的执行逻辑是希望利用 docker 对 dubbo-go 中的集成测试内容构建镜像,并启动容器进行测试,该镜像打包所用的 Dockerfile 路径在 github.com/apache/dubbo-go/test/integrate/dubbo/go-server
目录下,对照错误日志的 STEP 标识,我们可以定位到具体错误发生下面的两个步骤:
…
STEP 9
RUN test KaTeX parse error: Expected 'EOF', got '&' at position 18: …R_ORIGIN_REPO} &̲& go mod edit -…{PR_ORIGIN_COMMITID} || go get -u dubbo.apache.org/dubbo-go/v3@develop
…
STEP 11
RUN go mod tidy && go install github.com/apache/dubbo-go/test/integrate/dubbo/go-server
在 STEP 9 中,我们使用 go mod edit -replace
替换了 dubbogo 的依赖路径,将其替换为发起 PR 请求的仓库地址和 commit id。在此基础上,当镜像构建跑到 STEP11 ,尝试使用 go mod tidy
拉包时发生了错误。
回过头查看错误日志,我们可以发现:
由于我们只指定了 commit id,因此在 go mod 实际运行过程中,它会为我们生成一个假定版本号(关于假定版本号的更多说明可以查看本文最后的问题拓展),这个假定版本号抓取远程仓库的最新有效 tag 为 v1.4.1【注:此处远程仓库为 github.com/Mulavar/dubbo-go,这是我自己的 dubbo-go 分支,该分支拉取 fork 的时间比较早,其最后 tag 是 v1.4.1】,并自增为 v1.4.2,主版本是 v1。但在先前,我们的 dubbogo module path 是声明为 dubbo.apache.org/dubbogo/v3
,主版本是 v3,这导致了 go mod edit -replace
前后的依赖主版本分别是 v3 和 v1 ,出现了不一致,实际拉取 dubbogo 依赖的时候出错。
=========================================================================
在问题分析一节中我们定位到这个问题在镜像构建的 STEP 9,即:
STEP 9
RUN test KaTeX parse error: Expected 'EOF', got '&' at position 18: …R_ORIGIN_REPO} &̲& go mod edit -…{PR_ORIGIN_COMMITID} || go get -u dubbo.apache.org/dubbo-go/v3@develop
这一步,我们使用 go mod edit -replace
时将一个 v3 版本的 go module 替换成了一个 v1 版本的 module,导致主版本不一致发生错误,因此我们只需在替换依赖路径时指定替换后的 module 主版本也为 v3 即可,我们在 go mod edit -replace
后的模块依赖路径后也加上 v3 后缀如下所示。
修改前:
go mod edit -replace=dubbo.apache.org/dubbo-go/v3=github.com/{PR_ORIGIN_REPO}@${PR_ORIGIN_COMMITID}
⇒ 修改后:
go mod edit -replace=dubbo.apache.org/dubbo-go/v3=github.com/${PR_ORIGIN_REPO}/v3@${PR_ORIGIN_COMMITID}
修复该问题后我们提交代码查看 CI,在 STEP 8 打印的日志信息中,可以看到替换后的 dubbogo 路径多了 v3,并且在拉包的时候跟的版本号(v3.0.0-20210509140455-2574eab5ad0b
)主版本同样是 v3,成功拉取了依赖。
=========================================================================
在我们使用 Go modules 去构建项目的依赖关系时,对 go 项目的依赖都需要声明我们所使用的版本号,考虑到每次发布新版本时,兼容一直是开发者最为重视和头痛的问题,因此 go 通过**语义导入版本控制(Semantic Import Versioning)**来制定版本号的标准,来确保每个开发者能够根据自己的项目需求指定使用的依赖版本。根据 go 的语义导入版本控制准则,版本号由三部分构成:
注:上图及以上部分内容参考自《Go Modules 详解》一文。
其中 Major version 表示这是一个新的大版本,甚至这个新版本可能和旧版本是不兼容的。
而 Minor version 则表示这是一个大版本中的迭代,主要用于新增 feature 时递增。
Patch version 则是粒度最细的版本更新,表示一些 bug 的修复。
而指定主版本则有两种方式,一种是如上的直接声明,另一种则是在项目路径的最后加上版本后缀,如 dubbogo 3.0 版本声明的 module 则是 dubbo.apache.org/dubbo-go/v3
,其中 v3 就是一个主版本的声明。
Go 在使用依赖时推崇我们指定明确的版本号,比如 dubbogo 的 go.mod 中声明的对 cloud.google.com/go
的依赖:
但考虑到在某些场景下,我们想要使用模块依赖的某个未发版的版本(该模块只有一个已知的 commit id),如 dubbogo 声明的 github.com/Microsoft/go-winio
依赖,就可以使用一个假定版本号(pseudo-version
)去替代真实的版本号。假定版本号的格式为:
// (1) vX.0.0-yyyymmddhhmmss-abcdef123456
// (2) vX.Y.(Z+1)-0.yyyymmddhhmmss-abcdef123456
// (3) vX.Y.(Z+1)-0.yyyymmddhhmmss-abcdef123456+incompatible
// (4) vX.Y.Z-pre.0.yyyymmddhhmmss-abcdef123456
// (5) vX.Y.Z-pre.0.yyyymmddhhmmss-abcdef123456+incompatible
可以看到 pseudo-version
被短斜杠分为三部分,其中第一部分 X.Y.Z 与 4.1 节提到的一致,分别是 major version
、minor version
、patch version
,而第二部分是一个格式为 yyyymmddhhmmss 的时间戳,第三部分是一个 12 位的 commit hash,可以手动指定,如果没有,则由 go 自动生成。
关于 pseudo-version
,go 的生成规则如下:
-
查询该项目对应主版本(若项目依赖路径没有显式的 v2/v3 后缀,则默认为 v1 版本)的最新 tag。
-
有 tag 则使用最新 tag 递增 patch version。
-
无 tag ,根据项目路径带的后缀版本号自动生成(如 v3 则自动生成一个 3.0.0 开头的
pseudo-version
)。
遵循这个规则,回头看前文的问题分析和问题解决,我们就可以明白为什么在一开始 dubbo-go 的 pseudo-version
是 v1.4.2,这正是因为 go 认为 replace 后的 dubbogo 依赖主版本是 v1,去查找了该主版本下的最新 tag,并递增了 patch version
,从而导致前后主版本不一致,当我们对版本路径加上 v3 后,go 查找不到对应主版本下的 tag,为我们自动生成了 v3.0.0,从而通过了 CI 。
和 Java 不同,go 其实是没有子模块概念的。即使有些时候,我们会看到有个 repo 里有多个 Go modules,比如项目的根目录有一个 go.mod ,里面有些子目录里又有 go.mod 。
这在 Go modules 被称为嵌套模块,而非父子模块,即两个模块没有任何关系,是相互独立的。
那什么时候才需要单 repo 多模块呢?一般来说,碰到以下两种情况我们才会考虑使用单 repo 多模块的开发形式。
-
某个嵌套模块变动非常频繁,需要经常发版。
-
当中的嵌套模块仅仅依赖某个固定版本的根模块。
两种情况其实本质都是两个模块之间没什么强的版本绑定关系,但是由于一些其他原因需要放在一个 rpeo 下,因此形成了单 repo 多模块的局面。
dubbo-go 使用了静态文件映射的方式实现了模块重定向,静态文件的内容如下:
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数Go语言工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则几千的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年Go语言全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Golang知识点,真正体系化!
由于文件比较大,这里只是将部分目录大纲截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且后续会持续更新
如果你觉得这些内容对你有帮助,可以添加V获取:vip1024b (备注Go)
一个人可以走的很快,但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎扫码加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
2867248663)]
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Golang知识点,真正体系化!
由于文件比较大,这里只是将部分目录大纲截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且后续会持续更新
如果你觉得这些内容对你有帮助,可以添加V获取:vip1024b (备注Go)
[外链图片转存中…(img-DYBcNY9U-1712867248663)]
一个人可以走的很快,但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎扫码加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!