请教大佬， Golang 的 CI 如何按代码变更构建某个镜像？

[istomyang]

因为 Golang 项目可以包含多个二进制文件，那 CI 构建就需要考虑仅构建代码变更的镜像。

目前解决方案根据 commit scope 来定义影响范围，但难点在于共享包修改的情况，偷懒的话可以定义粗范围，比如某个共享包影响所有或者某个大范围的镜像。

我想问你们团队一般都是怎么解决的？感谢！

感谢大佬！

我们最终选定 scope 的方式，制定了 scope 文档定义影响范围。问题的难点在 共享包 的影响范围界定上，目前我们偷懒默认影响全部领域的构建，但是也提供了指定。

[just1]

用 bazel

[seth19960929]

分支法, 每个分支对应一个应用
文件夹法, 写 ci 判断文件夹变动了才去构建这个目录下的镜像
app/
/service1
/service2

[GenericT]

go/callgraph 从各个入口遍历，收集所有涉及到的文件，然后和 git diff 的结果再做一个 diff 就知道了。
不过我觉得有点多余，go 编译已经挺快的了，图啥，又不是 C++编译一个小时

[mshadow]

把多个二进制改成一个二进制的多个子命令，可以用 cobra 实现。比如，你之前是 编译出来 cli_a 、cli_b 、cli_c 三个二进制，现在用 cobra 改成一个程序入口，cli a, cli b, cli c 三个子命令，这样只有一个二进制，并且公用代码相当于只编译了一次

[lysShub]

为啥有多个二进制？不能合在一起吗？

[xhd2015]

@lysShub 确实，源代码可以分开，但是集成最好做在一起，提供一个统一的工具界面

[uliah]

我们增加了优先级 P (比如 com 和 app 俩个分类)， 确认 commit scope ， 根据 P 定义顺序，P.com 全部完成之后执行 P.app 部分 。 这方法比较通用，不仅是在 Golang 项目。

[just1]

针对大的 monorepo ，就一个方法，通过依赖图反查改动 package 的影响范围。但这个事情还是挺麻烦的，所以用 bazel 吧嘿嘿嘿，它设计思路就是这个。除了学习成本有点高，用了你就会喜欢上的