构建过程中的模块依赖项缓存问题 [英] Module dependency caching issue during build

问题描述

最近换用了Go 1.11版本，并试图将我们的项目转换为使用新的模块系统.但是，我在缓存系统方面遇到了一个令人沮丧的问题(到目前为止，由于过去不相关的问题，我一直使用GOCACHE=off进行操作，但这不是模块的选择).

Recently swapped to using Go 1.11 release and am trying to convert our projects over to using the new module system. However, I'm running into a frustrating issue with the caching system (I've thus far run with GOCACHE=off because of unrelated issues in the past, but that's not an option with modules).

以下命令日志是基于使用Homebrew对我的系统Go进行的全新升级到1.11(我通常使用gvm安装和管理Go版本，但是为此交换到系统构建中以查看是否是gvm).我将我的GOPATH设置为一个临时目录，并将源代码移出了默认的GOPATH(当前位于~/gotemp/statsbot).

The below command log is based on using a fresh upgrade of my system Go to 1.11 using Homebrew (I typically use gvm to install and manage Go versions, but swapped to system build for this to see if gvm was the issue). I set my GOPATH to a temporary directory and moved the source code out of the default GOPATH (it is currently at ~/gotemp/statsbot).

对于此命令日志，我首先对高速缓存进行操作，以使其处于全新状态.然后，我在进行构建(以提取所有缺少的依赖项，这也应重新缓存deps)，然后在其中一个子目录上进行测试.

For this command log, I'm nuking the cache first, to get it in a fresh state. I'm then doing a build (to pull in any missing dependencies, which should also recache deps) followed by a test on one of the subdirectories.

[08:34:48] statsbot (feature/bot-rebuild-gomod) $ rm -rf on

[08:34:49] statsbot (feature/bot-rebuild-gomod) $ go clean --cache

[08:34:50] statsbot (feature/bot-rebuild-gomod) $ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="on"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/var/folders/ck/bf8_n8hn34j7bh7hqqppxrtm0000gn/T/tmp.3ga5Iq09"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/Cellar/go/1.11/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.11/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD="/Users/kaedys/gotemp/statsbot/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/ck/bf8_n8hn34j7bh7hqqppxrtm0000gn/T/go-build065167780=/tmp/go-build -gno-record-gcc-switches -fno-common"

[08:34:53] statsbot (feature/bot-rebuild-gomod) $ go build .

[08:35:01] statsbot (feature/bot-rebuild-gomod) $ ginkgo stats
Failed to compile stats:

# golang.org/x/text/runes
/var/folders/ck/bf8_n8hn34j7bh7hqqppxrtm0000gn/T/tmp.3ga5Iq09/pkg/mod/golang.org/x/text@v0.3.0/runes/cond.go:10:2: can't open import: "golang.org/x/text/transform": open on/51/51b9b2cf5a27a7ff06942814ad6ef031de64dc6d773c835916067578ea1ae3a1-d: no such file or directory
# golang.org/x/text/encoding
/var/folders/ck/bf8_n8hn34j7bh7hqqppxrtm0000gn/T/tmp.3ga5Iq09/pkg/mod/golang.org/x/text@v0.3.0/encoding/encoding.go:19:2: can't open import: "golang.org/x/text/encoding/internal/identifier": open on/4c/4c2fad64312f6ec34b38755ccecb96bb31c6995211f39e0eb4112abc2fac560c-d: no such file or directory
# gopkg.in/fsnotify.v1
/var/folders/ck/bf8_n8hn34j7bh7hqqppxrtm0000gn/T/tmp.3ga5Iq09/pkg/mod/gopkg.in/fsnotify.v1@v1.4.7/kqueue.go:18:2: can't open import: "golang.org/x/sys/unix": open on/77/77790588f9aed90a52efdb1dac069953e1ea2bf82db8627a47a9492862b39c6e-d: no such file or directory

Ginkgo ran 1 suite in 4.123499564s
Test Suite Failed

在许多构建情况下，我都会看到相同的错误消息. go build .通常会成功，但有时会因类似的消息而失败.运行go clean --cache不变式可以解决这些问题，但是我真的不想在每次构建之前都运行它，并且在尝试使用Ginkgo进行测试时 无效，因为这似乎涉及多个连续步骤.

I see this same error message in a number of build situations. go build . will usually succeed, but sometimes will fail with similar messages. Running go clean --cache invariable fixes these issue, but I don't really want to run that before every build, and it doesn't work when trying to use Ginkgo to test since that seems to involve several successive compilations.

错误本身就是令人困惑的，因为这些文件 do 存在:

The error itself is what's baffling, because these files do exist:

[08:40:49] statsbot (feature/bot-rebuild-gomod) $ ll on/4c
total 112
-rw-r--r--  1 kaedys  staff  18346 Sep 14 08:40:19 2018 4c1d5db302dff0381c402160d7fd2bd89a6dafd3edc61b3dbd5e8f1a85108fb7-d
-rw-r--r--  1 kaedys  staff  27980 Sep 14 08:40:45 2018 4c2fad64312f6ec34b38755ccecb96bb31c6995211f39e0eb4112abc2fac560c-d
-rw-r--r--  1 kaedys  staff    175 Sep 14 08:40:20 2018 4cbbc40c46eba0ef41f3ebd23470c3327215fa6e05e269c276c6635da79f2e8e-a
-rw-r--r--  1 kaedys  staff     13 Sep 14 08:40:20 2018 4cffcbd4a7f1255ca3696f5e24e0b1045d14c25f1f90cbbb077b5d6f2d11e68c-d

ll中的第二个文件是缺少第二个错误消息的文件，因此我只能假定它是在仍在生成文件的同时尝试访问该文件，或者是在不同的目录(很难告诉，因为错误消息仅报告文件的相对路径).

The second file in that ll is the file the second error message complained was missing, so I can only assume that either it was trying to access the file while the file was still being generated, or it was looking in a different directory (which is difficult to tell, since the error message only reports a relative path for the file).

在此处发布以查看是否有人知道如何解决此问题，或者在我的环境设置中这是否很时髦，然后才在Go github上创建正式问题.

Posting here to see if anyone knows how to solve this or if it's something funky in my environment setup before creating an official issue on the Go github.

推荐答案

您的GOCACHE环境变量设置为"on". GOCACHE的值必须是一个文件夹，特殊的"off"值表示不缓存构建和测试结果，并且不使用那些已经缓存的数据.没有特殊值"on".

Your GOCACHE environment variable is set to "on". Value of GOCACHE must be a folder, and the special "off" value means to not cache build and test results and to not use already cached data of those. There is no special value "on".

您不必设置GOCACHE，因为它具有默认值.引用自命令转到:构建和测试缓存:

You don't have to set GOCACHE, as it has a default value. Quoting from Command Go: Build and test caching:

go命令缓存构建输出，以在以后的构建中重用.缓存数据的默认位置是当前操作系统的标准用户缓存目录中名为go-build的子目录.设置GOCACHE环境变量将覆盖此默认值，并且运行"go env GOCACHE"将打印当前的缓存目录.您可以将变量设置为"off"以禁用缓存.

The go command caches build outputs for reuse in future builds. The default location for cache data is a subdirectory named go-build in the standard user cache directory for the current operating system. Setting the GOCACHE environment variable overrides this default, and running 'go env GOCACHE' prints the current cache directory. You can set the variable to 'off' to disable the cache.

这篇关于构建过程中的模块依赖项缓存问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！