英文:
GO Monorepo: List of Files that need to be re-built using go build
问题
我有一个用于我的Go项目的monorepo设置。如果我能找到一种方法使用go build(或类似的内部工具)来获取需要重新构建的目标列表,那将非常好。
这是我正在寻找的示例:
...
├── pkg //跨mono repo的共享代码
│ └── math
│ └── common_operations.go
└── cmd //要构建的单独包
├── package1
│ └── main.go
└── package2
└── main.go
package1程序调用共享库中的subtract函数。package2程序调用add函数。
- 如果我更改package1的代码,只有package1的目标会被列出。
- 如果我更改package2的代码,只有package2的目标会被列出。
- 如果我更改共享库中的add函数,只有package2的目标会被列出。
- 如果我更改共享库中的subtract函数,只有package1的目标会被列出。
- 如果我更改共享库中的所有函数,package1和package2都会重新构建。
我很乐意使用内部构建包并以编程方式获取列表。只是我对它不太熟悉。
我尝试过的方法:
Bazel有一个选项可以实现这个,但如果可能的话,我更愿意避免使用Bazel。
bazel命令:bazel build cmd/some-target --check_up_to_date
如果是最新的,则返回错误代码0,否则返回错误代码1。
从技术上讲,这是一个解决方案,但我的需求是基于CI/CD的。我希望尽可能避免将Bazel集成到该流程中。
英文:
I have a monorepo setup for my go project. I would love it if I could find a way to use go build (or similar internal tool) to get a list of targets that need to be re-built.
Here is an example of what I am looking for:
...
├── pkg //shared code across mono repo
│ └── math
│ └── common_operations.go
└── cmd // individual packages to be built
├── package1
│ └── main.go
└── package2
└── main.go
The package1 program calls a subtract function from the math shared library. The package2 program calls an add function.
- If I change the package1 code, only the package1 target is listed
- If I change the package2 code, only the package2 target is listed
- If I change the add function in the shared library, only the package2 target is listed
- If I change the subtract function in the shared library, only the package1 target is listed
- If I change all the functions in the shared library, both package1 and package2 rebuilds.
I would be perfectly happy to use use the internal build package and get the list programatically. I am just am unfamiliar with it.
What I have tried:
Bazel has an option for this but I would prefer to avoid using bazel if at all possible.
the bazel command: bazel build cmd/some-target --check_up_to_date
returns error code 0 if it is up to date, otherwise it returns error code 1.
Which is technically a solution, but my need, as you might have inferred, is ci/cd based. And I want to avoid integrating Bazel into that process as much as possible.
答案1
得分: 1
不太确定这里的用例,你是否愿意实际编译这些软件包?如果是这样的话,也许可以使用go build -v
来完成任务。根据go help build
的说明:
-v
在编译软件包时打印软件包的名称。
英文:
Not really sure of the use case here, are you OK with actually compiling the packages as well? In that case maybe go build -v
can do the job for you. From go help build
:
-v
print the names of packages as they are compiled.
答案2
得分: 0
我的愿望是找到类似于"go build"选项的东西,它可以根据目标包是否是最新的来返回true或false。如果有人找到了一个能解决这个问题的工具(比如Earthly),我会很高兴的。
我找到的最接近解决方案的方法是运行以下命令:
go build -n cmd/some-target
如果输出是:
touch some-target
那么它就是最新的。如果输出是一长串命令,那么它就不是最新的。
如果它不是最新的,你可以使用以下命令获取包名:
go build -v
以便将其移至CI流程的下一个阶段(构建目标、测试目标、构建镜像等)。
显然,这是一个有点巧妙的方法,需要自己编写一个解决方案,并且具体的细节可能需要根据你的实际需求进行更改。正如@zacho314提到的,它还需要保存go build缓存的状态,但是大多数现代CI技术都有解决方案。我确定我现在会采取类似的方法。
英文:
My desire was to find something similar to a go build option that would basically spit out a true or false if a target package was up-to-date. I would be happy if someone out there found a tool ( Earthly I am looking at you right now) that could solve this.
The closest thing to a solution I could find to solve my issue was to run this command:
go build -n cmd/some-target
And if the output is:
touch some-target
Then, it must be up-to-date. If the output is a long list of commands, then it isn't.
If it is not up-to-date. You could then get the package name using:
go build -v
To get the name of the package and move it to the next stage of the CI process (building target, testing target, building image, etc).
Obviously it is a little hacky and requires self-rolling a solution and specifics would likely need to be changed on your exact needs. It also requires, as @zacho314 mentioned, saving the state of the go build cache, but most modern CI technologies have a solution for that. I am sure I will do something similar to this for now.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论