go

Tool builder: gcr.io/cloud-builders/go

The gcr.io/cloud-builders/go image is maintained by the Cloud Build team, but it may not support the most recent features or versions of Go. We also do not provide historical pinned versions of Go.

The Docker community maintains the golang image which includes additional Go tooling and supports multiple tagged versions across several platforms.

To migrate to the golang image, make the following changes to your cloudbuild.yaml:

- name: 'gcr.io/cloud-builders/go'
+ name: 'golang'
+ entrypoint: 'go'

Go Modules

The functionality previously provided by gcr.io/cloud-builders/go in prepare_workspace is replaced by the use of Go modules, available since Go 1.11. Once this builder upgrades to Go 1.16, go modules will become the default behavior. To continue using the legacy behavior after the upgrade, set GO111MODULE=on in your cloudbuild.yaml.

See examples/module for a working example.

Note #1 /workspace and /go

The Golang image defaults to a working directory of /go whereas Cloud Build mounts your sources under /workspace. This reflects the recommended best practice when using Modules of placing your sources outside of GOPATH. When you go build ./... you will run this in the working directory of /workspace but the packages will be pulled into /go/pkg.

Because /go is outside of /workspace, the /go directory is not persisted across Cloud Build steps. See next note.

Note #2 Sharing packages across steps

One advantage with Go Modules is that packages are now semantically versioned and immutable; once a package has been pulled, it should not need to be pulled again. Because the golang image uses /go as its working directory and this is outside of Cloud Build's /workspace directory, /go is recreated in each Golang step. To avoid this and share packages across steps, you may use Cloud Build volumes.

Here is an example to prove the point; this example uses go mod init as the first step rather than creating a go.mod:

steps:
- name: 'golang'
  args: ['go','mod','init','github.com/golang/glog']
- name: 'golang'
  args: ['go','list','-f','{{ .Dir }}','-m','github.com/golang/glog']
options:
  volumes:
  - name: go-modules
    path: /go

Note that this examples defines volumes as a global build option (rather than on each build step). This allows the /go directory to be shared across steps -- it's initialized in the first and used in the second.

NB Cloud Build supports using build-wide settings for env and volumes using options (see link).

See examples/multi_step for a working example.

Note #3 Golang Module Mirror

The Go team provides a Golang Module Mirror (https://proxy.golang.org/). The module mirror is enabled by default for Go 1.13 and newer. You may utilize the Mirror by including GOPROXY=https://proxy.golang.org in your build steps, e.g.:

- name: golang
  env:
  - GOPROXY=https://proxy.golang.org
  args: ['go','get','-u','github.com/golang/glog']
  volumes:
  - name: go-modules
    path: /go

Using gcr.io/cloud-builders/go

This builder runs the go tool (go build, go test, etc.) after placing source in /workspace into the GOPATH before running the tool.

alpine vs debian

There are two supported versions of this builder, one for alpine and one for debian. The difference is significant since, by default, Go dynamically links libc. Binaries built in an alpine environment don't always work in a debian-like (including ubuntu, etc) environment, or vice versa.

The specific versions are available as

• gcr.io/cloud-builders/go:alpine
• gcr.io/cloud-builders/go:debian

And gcr.io/cloud-builders/go:latest is an alias for gcr.io/cloud-builders/go:alpine.

This tool builder sets CGO_ENABLED=0, so that all binaries are linked statically.

Output files

If you use the install subcommand, the binaries will end up in $GOPATH/bin which is unlikely to be in your /workspace. You may want to use go build -o <target> instead.

Building this builder

To build this builder, run the following command in this directory.

$ gcloud builds submit