Skip to content

Remove explicit use of GOROOT/GOPATH now that we're using Go modules

Arran Walker requested to merge ajwalker/golang-gopath into main

What does this MR do?

For Windows, we would previously symlink the build directory to one under GOPATH, which was once required when we were not using Go modules.

GOROOT and GOPATH are also explicitly defined unnecessarily for some of the Linux jobs.

GO111MODULE: "on" is explicitly set because we're still using Go 1.13. When we upgrade, this becomes the default and can be removed.

Why was this MR needed?

Recent changes I was making as part of another MR had me using go install. This would adhere to the GOPATH, but it wasn't the path that the Go installation had already set up upon installation. This meant additional steps to update the PATH with the new (non-default) binary installation path.

This is cruft that was once necessary left over from using previous Go versions.

What's the best way to test this MR?

N/A: If our pipeline/tests pass, we're good.

The artifact paths removed have been unused for some time. Looking at previous helper images jobs in our pipeline all contain:

WARNING: .gopath/bin: no matching files            
WARNING: .gopath/.ok: no matching files

What are the relevant issue numbers?

Closes #28029 (closed)

Edited by Arran Walker

Merge request reports