Solve the problem of error obtaining VCS status: exit status 128 when building in container after Golang upgrade to 1.18+

Leave a Comment / 14/08/2022 /

Intro

Golang is a very magical language. Its syntax is not very complicated, and the compiled program is a Binary. It can be run without installing any additional runtime. If you want to write a small program such as Hello World, you can quickly follow the tutorial. Write it out. If you want to write a slightly more complicated web application, you just need to find a web framework, such as Gin, Fiber, etc. You can also have a similar experience with ExpressJS, you can see that people like me who can hardly write code can also Write a web program like WebP Server Go with the reference and assistance of BennyThink, GitHub Copilot and a lot of Stackoverflow answers.

Of course, Go also has many incredible points. For example, it does not have a centralized package management platform like pypi and npm. All programs written in Golang import a bunch of things from github.com, such as:

 import ( "fmt" "math" "regexp" "strconv" "unicode" "github.com/pingcap/errors" "github.com/pingcap/tidb/parser/ast" "github.com/pingcap/tidb/parser/auth" "github.com/pingcap/tidb/parser/charset" "github.com/pingcap/tidb/parser/mysql" "github.com/pingcap/tidb/parser/terror" "github.com/pingcap/tidb/parser/types" )

When GitHub is gone, I really don’t know how to import these packages. In addition, there are problems such as GOPATH. It is very inexplicable to see that many people put all their Go projects under /home/User/go/ for development. .

WebP Server Go Upgrade

Since Go 1.17 version has been EOL, we upgraded the build version of WebP Server Go. Since Golang upgrade is generally a matter of changing a mirror, we will build the mirror from:

 FROM golang:1.17.4-alpine as builder

replaced by

 FROM golang:1.19.0-alpine as builder

Very simple, and soon, CI told us that the image build was unsuccessful (this kind of event will cause someone to shout in some companies: “CI is down, @xxx look”):

https://github.com/webp-sh/webp_server_go/runs/7784058473?check_suite_focus=true

 #14 [builder 6/6] RUN cd /build && sed -i "s|.\/pics|/opt/pics|g" config.json && sed -i "s|""|"/opt/exhaust"|g" config.json && sed -i 's/127.0.0.1/0.0.0.0/g' config.json && go build -ldflags="-s -w" -o webp-server . #14 0.395 error obtaining VCS status: exit status 128 #14 0.395 Use -buildvcs=false to disable VCS stamping. #14 ERROR: process "/bin/sh -c cd /build && sed -i \"s|.\\/pics|${IMG_PATH}|g\" config.json && sed -i \"s|\\\"\\\"|\\\"${EXHAUST_PATH}\\\"|g\" config.json && sed -i 's/127.0.0.1/0.0.0.0/g' config.json && go build -ldflags=\"-s -w\" -o webp-server ." did not complete successfully: exit code: 1

After searching in Chinese, CSDN told me two options:

Fortunately, the latter is a reliable solution except that the technology may be a bit unskilled. Let’s take a look at what this thing is.

From the Release Note of Go 1.18, you will find this passage:

The go command now embeds version control information in binaries. It includes the currently checked-out revision, commit time, and a flag indicating whether edited or untracked files are present. Version control information is embedded if the go command is invoked in a directory within a Git, Mercurial, Fossil, or Bazaar repository, and the main package and its containing main module are in the same repository. This information may be omitted using the flag -buildvcs=false .

It can be seen that since Go 1.18, Go comes with Version control, which means that if you are in a Git directory and this directory has a broken .git directory, you can use go build and other operations. The above problems will be encountered, but why there is a broken .git directory in the build environment?

This has to start with someone adding the .dockerignore file. Due to lack of skill, our .dockerignore was written as .git/* at the beginning, which caused the directory itself to not be Ignore removed (and this problem is not It’s really hard to see when something goes wrong. After all, when someone builds an image, they go to the Dockerfile and add a sentence ls -a to see what is passed in. I don’t know if I don’t see it, but I find that everyone is basically in it:

 #0 0.071 . #0 0.071 .. #0 0.071 .dockerignore #0 0.071 .git #0 0.071 .github #0 0.071 .gitignore #0 0.071 .idea #0 0.071 Dockerfile #0 0.071 builds #0 0.071 config.go #0 0.071 config.json #0 0.071 coverage.txt #0 0.071 encoder.go #0 0.071 encoder_test.go #0 0.071 exhaust #0 0.071 go.mod #0 0.071 go.sum #0 0.071 helper.go #0 0.071 helper_test.go #0 0.071 pics #0 0.071 prefetch.go #0 0.071 prefetch_test.go #0 0.071 remote-raw #0 0.071 router.go #0 0.071 router_test.go #0 0.071 scripts #0 0.071 update.go #0 0.071 update_test.go #0 0.071 webp-server.go #0 0.071 webp-server_test.go #0 0.161 error obtaining VCS status: exit status 128 #0 0.161 Use -buildvcs=false to disable VCS stamping. ------

Since .git/* is written, there will be an empty .git directory in the build environment. If you add a git status to the Dockerfile , you can see:

 > [builder 6/7] RUN cd /build && git status: #0 0.078 fatal: not a git repository (or any of the parent directories): .git

So here leads to the above error.

Knowing what’s going on, we can solve this problem in a targeted manner. If you build applications in containers like us, you can:

  • Add a line directly to .dockerignore :
 .git

To let Docker build directly without copying the .git directory to the build environment.
* Or it can be ugly, add a line rm -rf .git to the Dockerfile , of course, this is a bit weird, if the local .git directory is too large, COPY . This kind of operation will be very stuck
* Or you can downgrade the Go version to below 1.18

If you’re building your application outside of the container and your Git repository has a problem (whether it’s a permissions issue or something), just add -buildvcs=false to the build parameters.

Epilogue

The problem we encountered was made up of two problems:

  1. .dockerignore file was not written correctly at the beginning
  2. When upgrading, I did not read the release note completely, but took it for granted that I changed the image version to build (of course, this -buildvcs is also a bit strange to be enabled by default)

The disadvantage is that it blocked our development for a while, and the advantage is that it helped us discover a problem that we had not noticed before. Maybe this is an “industrial-grade language”.

After fixing this problem, we started to fight against the error report when parsing the image in the official Golang library. Who would have thought that to parse an image in a language, we need to os.Open() after png.Decode() , and also What about errors like invalid format: invalid checksum and corrupted: invalid JPEG format: missing 0xff00 sequence ? Can refer to: https://github.com/webp-sh/webp_server_go/issues/137 .

This article is reprinted from https://nova.moe/solve-go-buildvcs/
This site is for inclusion only, and the copyright belongs to the original author.

Leave a Comment