Add GOCACHE to env for Golang 1.12 compilation error

[jspawar]

Hello @viovanov and team,

Ran into some issues with the packaging script for the BOSH release when we were deploying things with BOSH.

Golang 1.12 seems to want either GOCACHE or HOME set in the environment where a go program is being compiled in. HOME appears to not be set always for BOSH compilation VMs so we are mitigating this by setting GOCACHE

Without this set, we see the following error when deploying Eirini via BOSH:

Task 1674 | 17:16:14 | Error: Action Failed get_task: Task 02d85ada-2dd5-4d02-53e5-6fbf29723354 result: Compiling package eirini: Running packaging script: Running packaging script: Command exited with 1; Stdout: , Stderr: + mkdir -p /var/vcap/packages/eirini/src

• cp -a . /var/vcap/packages/eirini/src
• export GOPATH=/var/vcap/packages/eirini
• GOPATH=/var/vcap/packages/eirini
  ++ readlink -nf /var/vcap/packages/golang
• export GOROOT=/var/vcap/data/packages/golang/685d1b0f3bedb587617b9d279eb7cc1283ddccfd
• GOROOT=/var/vcap/data/packages/golang/685d1b0f3bedb587617b9d279eb7cc1283ddccfd
• export PATH=/var/vcap/data/packages/golang/685d1b0f3bedb587617b9d279eb7cc1283ddccfd/bin:/var/vcap/bosh/bin:/usr/local/bin:/usr/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin
• PATH=/var/vcap/data/packages/golang/685d1b0f3bedb587617b9d279eb7cc1283ddccfd/bin:/var/vcap/bosh/bin:/usr/local/bin:/usr/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin
• pushd /var/vcap/packages/eirini/src/code.cloudfoundry.org/eirini/cmd/opi
• go build -o /var/vcap/packages/eirini/bin/opi
  build cache is required, but could not be located: GOCACHE is not defined and neither $XDG_CACHE_HOME nor $HOME are defined

---

This can be mitigated as well by using the BOSH vendor package for golang which sets this for you in its compilation and runtime environments it provides: https://github.com/bosh-packages/golang-release/blob/d4ac25f9683908113db4d007a664f4f36a3b1b34/src/1.12/compile.env.linux#L8

Thank you!

Jwal

[jenspinney]

Ah, I didn't realize this was a separate PR.

This is also included in the next PR (#8 ). @viovanov I think you can close this one so it doesn't conflict with the other. Or, if you prefer them separate, I can rebase away this comment from PR #8.