go - 为什么 go 模块在没有详细信息的情况下会在提取某些有效的正确提交时失败？

Question

我的 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 get fetching 的 go build 调用中存储库？最终，这是我遇到的问题的症结所在。

Answer 1

这个问题的答案是:这个问题是基于一个错误的前提。

也就是说，我最初假设我的 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 build 对存储库的获取是以不确定的顺序完成的，正如您在以下日志中看到的那样(查看 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 ，你应该查看失败前的所有日志，找到错误信息，永远不要假设错误报告之前的最后一个操作是实际失败的操作。

我不知道发生错误后 go build 需要多长时间才能“失败”，但是似乎确实会发生某些错误，并且 gomodules 会在一段时间内继续尝试做更多的工作来处理各种其他并发发现/获取操作。

TL;DR，go build 里面有并发元素，调试复杂的模块拉取时要注意。