为什么go模块在没有详细信息的情况下会失败，从而导致某些有效的正确提交？

2024-05-03 • 问答

我在go.sub文件github.com/prometheus/common v0.0.0-20190416093430-c873fb1f9420中的上游存储库中有一个依赖项，该文件显然存在于现实世界中：https://github.com/prometheus/common/commit/c873fb1f9420b83ee703b4361c61183b4619f74d。是否有任何原因导致在我的构建中执行的finding:...步骤失败了。

这显然是有效的SHA ...，但是，当我运行构建时，会得到以下输出：

2019-11-05 06:24:37 gobuilds.Compile : 06:24:37.496 calico_all_build INFO         go: finding github.com/prometheus/common v0.0.0-20190416093430-c873fb1f9420
2019-11-05 06:24:41 gobuilds.Compile : 06:24:41.644 calico_all_build INFO         go: error loading module requirements
2019-11-05 06:24:42 gobuilds.Compile : 06:24:42.425 calico_all_build INFO         make[1]: *** [bin/calico-typha-amd64] Error 1

我使用的版本是1.12.8（编辑，之前有错字）。

更新

我有一个后续问题-有没有一种方法可以将细粒度的调试信息添加到go构建调用中，从而导致存储库go get fetching？最终，这是我所面临的问题的症结所在。

该问题的答案是：该问题基于错误的前提。

也就是说，我最初认为go build失败之前的最后一条语句是失败的，但是我错了。实际上，如果模块不是可拉式的，您将为其获取明确的错误报告，例如：

go: github.com/golang/glog@v0.0.0-20160126235308-23def4e6c14b: unexpected status (https://***.***@artifacts.domain.com/api/go/go-domain/github.com/golang/glog/@v/23def4e6c14b.mod): 404 Not Found

但是在构建失败并报告为未满足模块要求之前，您可能会执行更多成功操作。因此，如果您的模块从根本上被破坏，则每次可能会获得完全不同的构建日志。这是因为go build触发获取finding操作的本质-如果（1）启用了Go模块并且（2）您要搜索的go模块不是在当前的GOPATH中，您将看到类似以下内容：

jayunit100@k8s-vmware:~/mygoapp# go build
go: finding github.com/jayunit100/blah v1.2.3
go: downloading github.com/jayunit100/blah v1.2.3

也就是说，该模块在构建时被拉低，但是，您可以在下面的日志中看到go go的存储库的获取以不确定的顺序进行（请参见logrus的下载开始，在此期间开始其他几次下载，然后半秒后，logrus的提取随后发生。

2019-11-06 11:46:46 gobuilds.Compile : 11:46:46.438 calico_all_build INFO         go: downloading github.com/projectcalico/logrus v1.0.4-calico
2019-11-06 11:46:46 gobuilds.Compile : 11:46:46.440 calico_all_build INFO         go: downloading github.com/prometheus/client_golang v0.9.1
2019-11-06 11:46:46 gobuilds.Compile : 11:46:46.444 calico_all_build INFO         go: downloading github.com/docopt/docopt-go v0.0.0-20160216232012-784ddc588536
2019-11-06 11:46:46 gobuilds.Compile : 11:46:46.454 calico_all_build INFO         go: downloading k8s.io/client-go v12.0.0+incompatible
2019-11-06 11:46:46 gobuilds.Compile : 11:46:46.477 calico_all_build INFO         go: downloading k8s.io/apimachinery v0.0.0-20190612205821-1799e75a0719
2019-11-06 11:46:46 gobuilds.Compile : 11:46:46.504 calico_all_build INFO         go: downloading github.com/coreos/go-semver v0.3.0
2019-11-06 11:46:46 gobuilds.Compile : 11:46:46.510 calico_all_build INFO         go: extracting github.com/projectcalico/logrus v1.0.4-calico

最终在上述问题中，发生的故障实际上与日志记录中的存储库无关，而与在构建阶段更早就被拉下的存储库相关联。

也就是说，当您发现go模块fetch和go模块error loading module requirements紧随其后时，应该查看故障之前的所有日志，以查找错误消息，并且永远不要假设错误报告之前的 last 操作是失败的 actual 操作。

我不知道发生错误后go build最终要花费多长时间才能失败，但是看来确实会发生某些错误，gomodules将继续尝试在一段时间内对各种任务进行更多工作其他并发的查找/获取操作。

TL; DR，go build中包含并发元素，在调试复杂模块请求时要注意这一点。

为什么go模块在没有详细信息的情况下会失败，从而导致某些有效的正确提交？

yzg338 回答：为什么go模块在没有详细信息的情况下会失败，从而导致某些有效的正确提交？

大家都在问