Setting GO environment variables (GOPATH, GOBIN) about setup-go

[radu-matei]

I agree with @lmittmann here - provide sane defaults for $GOPATH and $GOBIN, and allow users to change them if needed.

Also, it would be really convenient if the source code was placed in $GOPATH/{repository} directly.

[crazy-max]

Hi guys,

I also encountered this problem and I managed to solve it by adding this step. Works on all environments:

      -
        name: Set GOPATH
        # temporary fix
        # see https://github.com/actions/setup-go/issues/14
        run: |
          echo "##[set-env name=GOPATH;]$(dirname $GITHUB_WORKSPACE)"
          echo "##[add-path]$(dirname $GITHUB_WORKSPACE)/bin"
        shell: bash

[radu-matei]

I understand the hesitation - that being said, samples in the readme showing what needs to be done for $GOPATH and non-$GOPATH scenarios would be really helpful.

Thanks!

[damccorm]

Ok, have put some more thought into this and I think I agree that we should provide defaults here. Here's my current wip plan:

• GOPATH gets set to the current working directory. Unless you intentionally do something funny here (e.g. change the working-directory, this will be the root of your repository.
• GOBIN gets set to $GOPATH/bin.
• If the user scopes GOPATH or GOBIN into the step via the env block, those paths will be respected. So for example if your workflow looks like:

steps:
- uses: actions/setup-go@v1
  with:
    version: '1.12'
  env:
    GOPATH: $HOME

then GOPATH would be set to $HOME and GOBIN would be set to $HOME/bin

• Both GOPATH and GOBIN are added to the path
• $GOPATH/bin and $GOPATH/pkg are created if necessary.

Thoughts? Does that make sense?

[kjk]

• GOPATH gets set to the current working directory. Unless you intentionally do something funny here (e.g. change the working-directory, this will be the root of your repository.

I think it's better to keep GOPATH outside of the checked out code i.e. the current value of /home/runner/go seems fine.

Let's assume that my kjk/notionapi repo is checked out under /home/runner/work/notionapi.

If GOPATH is also /home/runner/work/notionapi, if I do go get honnef.co/go/tools/cmd/staticcheck to install staticcheck (to run it as part of workflow), the binary will be installed in my repo /home/runner/work/notionapi/bin/staticcheck and go.mod will be modified.

This is probably fine most of the time but I bet that it'll break tests for some people because they didn't expect the checkout to be polluted by artifacts of go get.

This also allows relatively easy work-around for people still relying on GOPATH as opposed to modules.

Assuming that my kjk/notionapi repo relies on GOPATH, it seems I could use path arg to actions/checkout and set it to /home/runner/go/src/github.com/kjk/notionapi and everything else should just work.

When GOPATH is the same as checkout / working directory, more gymnastics will be needed to move the source around.

[peterwillcn]

- run: |
    export PATH=$PATH:$(go env GOPATH)/bin
    go get -u golang.org/x/lint/golint
    golint -set_exit_status ./...

[nathany]

GOPATH is being slowly phased out.

I'm adopting this approach for tools like golint via the Go Wiki.

Even a matrix build on the past few versions of Go (go 1.11 through go 1.13) could work without GOPATH if using modules. An example in the README of checking out code to the GOPATH would be useful for projects that aren't yet using Go modules, but I don't think GOPATH should be set (to the workspace).

Setting GOBIN to $PWD/bin or similar, and adding GOBIN to to the front of the PATH would be handy, though I don't know if it's possible for environment variable changes in setup-go to persist to other steps? I think just including golint in the docs would help people out.

- name: Lint
  run: |
    GOBIN=$PWD/bin go install golang.org/x/lint/golint
    ./bin/golint ./...

[crazy-max]

@bryanmacfarlane Maybe it's time to review #19? 😇

[lmittmann]

I would expect to have GOPATH = $(go env GOPATH).

[mvdan]

I don't think setup-go should be setting GOPATH at all. Recent Go versions already deafult this to $HOME/go, and I agree with others that the current directory should not be inside GOPATH.

The same applies to GOBIN; it already defaults to $GOPATH/bin. Why do we need to set it explicitly? I've only seen it used like $GOBIN/some-binary when PATH isn't being set up correctly, but we can just fix that instead.

[bryanmacfarlane]

Hey All, I'm digging into this right now. Summary:

@mvdan - Agreed, I don't think it should set GOPATH as it's being phased out. On 1.13 forward, if you're working with modules, it's the wrong thing to do as modules must be outside the GOPATH

IF it should be set as a convenience, it should be relative to workspace.

Since the runner pulls source into the workspace, @crazy-max suggestion is best I believe

        name: Set GOPATH
        # temporary fix
        # see https://github.com/actions/setup-go/issues/14
        run: |
          echo "##[set-env name=GOPATH;]$(dirname $GITHUB_WORKSPACE)"
          echo "##[add-path]$(dirname $GITHUB_WORKSPACE)/bin"
        shell: bash

But I think if >= 1.13, it may very well be the wrong thing to do.

Options ...

GOPATH:

1. Don't set
2. Set only if less than 1.13
3. don't set and offer yaml input boolean whether to set (and do smart set ☝️ )

Leaning toward 3

GOBIN:
Add workspace/bin to the PATH. Even if that's not where your bin is for some reason, it doesn't break anything to have it in the path.

Thoughts?

[damccorm]

Since its not totally inferable what these should be set to, we leave them unless the user provides a value. What would your expectation be here?

[radu-matei]

FWIW, I don't think it's reasonable to expect users to setup a simple Go build that needs to run in the GOPATH in the following way:

    - name: Build
      run: |
        export GOPATH=$HOME/go
        export GOBIN=$(go env GOPATH)/bin
        export PATH=$PATH:$GOPATH
        export PATH=$PATH:$GOBIN
        mkdir -p $GOPATH/pkg
        mkdir -p $GOBIN
        mkdir -p $GOPATH/src/github.com/$GITHUB_REPOSITORY
        mv $(pwd)/* $GOPATH/src/github.com/$GITHUB_REPOSITORY
        cd $GOPATH/src/github.com/$GITHUB_REPOSITORY

[radu-matei]

This looks good to me, thanks!

Additional comments:

• on any Go version that still relies on $GOPATH, the source code must be moved in $GOPATH/src/github.com/{org/user}/{repo}

• $GOPATH/bin and $GOPATH/pkg must exist

Is there any chance all of these would be provided by default?

[damccorm]

$GOPATH/bin and $GOPATH/pkg must exist

That makes sense, updated my comment accordingly to create these if necessary.

on any Go version that still relies on $GOPATH, the source code must be moved in $GOPATH/src/github.com/{org/user}/{repo}

Want to make sure I understand correctly - you're suggesting that we rearrange the directory structure so that it looks like:

- $GOPATH
-- bin
-- pkg
-- src
--- github.com
---- {org/user}
----- {repo}
------ {repo contents}

I see why this is desirable, but I'm a little hesitant to do something that heavy/of that magnitude - to do that we'd need to move the entire repo and it would be hard to make it completely transparent to the end user what was happening. I'm more inclined to leave that for the user to do in a script step (though maybe we can provide some examples on the Readme).

Does that seem reasonable?

[vcabbage]

I modified my fork to add the bin directories to PATH based on the output of go env. This will use the default locations or the env var if set. I'd be happy to contribute these changes if desired. (I also added support for installing "tip", which is a requirement for me. I can separate that logic out.)

Few notes:

• GOPATH/{pkg,src,bin} directories will be created by the toolchain as needed, no need to create them explicitly.
• I agree that setting GOPATH to the workspace directory is probably not wanted in many cases.
• Another complication that arises from attempting to place the checkout in the proper GOPATH location is vanity imports. For example, though my repo is github.com/vcabbage/amqp it uses vanity imports and must be placed at GOPATH/src/pack.ag/aqmp.

[radu-matei]

Of course people will invariably have opinions about this.
Regardless, a combination of documentation and configuration (user input that determines which paths should be set, for example) should be enough to cover all preferences.

[kjk]

I don't think setup-go should be setting GOPATH at all. Recent Go versions already default this to $HOME/go,

I think it would be good GOPATH to be consistent across Go versions.

When it's set by default by Go toolchain to $HOME/go, leave it alone.

If it's not set by default, do set it.

Otherwise people will have to do it themselves in scripts as long as they use Go versions that don't set it by default.

[mvdan]

Fair enough, I guess it's fine to set GOPATH=$HOME/go for older Go versions. Noone should run into any inconsistencies, as long as they use $(go env GOPATH) and not $GOPATH directly.

[kjk]

I think $(go env GOPATH) wouldn't work on Windows.

[mvdan]

I keep forgetting that the default Windows shell is cmd :) I don't think it matters much as long as #14 is fixed.

[crazy-max]

As stipulated in doc:

For convenience, add the workspace's bin subdirectory to your PATH:

$ export PATH=$PATH:$(go env GOPATH)/bin

The scripts in the rest of this document use $GOPATH instead of $(go env GOPATH) for brevity. To make the scripts run as written if you have not set GOPATH, you can substitute $HOME/go in those commands or else run:

$ export GOPATH=$(go env GOPATH)

So maybe this part of code should be changed: https://github.com/actions/setup-go/blob/master/src/installer.ts#L112-L121

[bryanmacfarlane]

GO BIN was fixed as part of this issue: #14 - it's available today in v2-beta.

The action won't add GOPATH since that's on it's way out

[bryanmacfarlane]

Closing in favor of getting feedback on GOBIN in issue #14