Support for Outputting or Exporting Go Environment Variables

Version

actions/setup-go@v2

Description

In some of our GitHub Actions workflows, we opt to cache the GOCACHE between jobs to save compilation time. It seems like we currently need to run go env GOCACHE to fetch the correct GOCACHE path after this action is run, e.g.

jobs:
  example:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - uses: actions/setup-go@v2
      with:
        go-version: "1.14"
    - name: go env
      run: |
        echo "::set-env name=GOCACHE::$(go env GOCACHE)"
    - uses: actions/cache@v2
      with:
        path: ${{ env.GOCACHE }}
        key: ${{ runner.os }}-GOCACHE-${{ hashFiles('go.sum') }}-${{ hashFiles('src/**') }}

Since this action already runs go env, it would be great if those values were either available as outputs, e.g.

jobs:
  example:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - uses: actions/setup-go@v2
      id: setup_go
      with:
        go-version: "1.14"
    - uses: actions/cache@v2
      with:
        path: ${{ steps.setup_go.outputs.GOCACHE }}
        key: ${{ runner.os }}-GOCACHE-${{ hashFiles('go.sum') }}-${{ hashFiles('src/**') }}

Or if we could configure environment variables to automatically be exported:

jobs:
  example:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v2
    - uses: actions/setup-go@v2
      with:
        go-version: "1.14"
        export-environment-variables: [GOCACHE]
    - uses: actions/cache@v2
      with:
        path: ${{ env.GOCACHE }}
        key: ${{ runner.os }}-GOCACHE-${{ hashFiles('go.sum') }}-${{ hashFiles('src/**') }}

Thank you for the consideration! Please reach out if I'm missing something and this is already possible or if this would be acceptable as an enhancement.

@bflad

Hi @bflad ! Sorry for the late response!
Could you please clarify if the issue is still actual for you?
Thanks!

It definitely helps make workflow definitions platform agnostic. For example, it would allow all three platform specific cache action examples to be replaced with a single more robust example:

- uses: actions/cache@v2
  with:
    path: |
      ${{ steps.setup_go.outputs.GOCACHE }}
      ${{ steps.setup_go.outputs.GOMODCACHE }}
    key: ${{ runner.os }}-go-${{ hashFiles('**/go.sum') }}
    restore-keys: |
      ${{ runner.os }}-go-

This particular use case may not be as relevant if setup-go had a cache input (like setup-node) to handle cache setup.

@Sergey-Murtazin

Hi @Sergey-Murtazin 👋 Certainly still valid for our use cases, mostly to help with platform agnostic workflows as mentioned above. Thanks!

I was about to open a similar issue 🙂

I'm interested in GOPATH and I know it's pretty simple to retrieve it, but having it as an output of the action would make the workflows cleaner IMHO.

A JSON output of go env would work too.

It'd be helpful to have go env as outputs from this action so that it's not necessary to solve for GOBIN, GOPATH, GOCACHE in the worflow.

I've opened a #334 with some default outputs that I think will cover 99% of the cases, let me know what you think 🙏

Run

Would love this as well. I currently have extra steps like echo "dir=$(go env GOMODCACHE)" >> ${GITHUB_OUTPUT}, which are verbose and wasteful, since setup-go has already run go env.

Additionally, please let us know if there are any specific use cases where having these outputs would be beneficial. This helps us understand your requirements better and further enhance the action.

The built-in cache functionality now covers the original cache-path use case from this issue. For the common case, users no longer need to manually export GOCACHE and GOMODCACHE just to configure Go module/build-output caching, because setup-go already restores and saves the paths from:

go env GOMODCACHE
go env GOCACHE

So I would consider the original standard-cache motivation mostly addressed.

To check whether the broader output request still has value, I done a cursory GitHub search (source). The sampling focused on workflows, composite actions, shell scripts, Makefiles, Dockerfiles, and documentation snippets that call go env and then pass the result into $GITHUB_ENV, $GITHUB_OUTPUT, or $GITHUB_PATH.

The main conclusion is that built-in caching solves the standard GOCACHE/GOMODCACHE cache setup case, but it does not replace Go environment outputs in general. Code-search samples show continuing use cases such as:

GOPATH / GOPATH/bin: commonly used after go install to add installed tools to PATH.
GOBIN: used to find the effective Go binary install directory, often with fallback to GOPATH/bin.
GOROOT: used to locate files inside the installed toolchain, such as wasm_exec.js, LICENSE, or bin/go.
GOTOOLDIR: used by advanced workflows that invoke or inspect Go toolchain binaries like compile, link, or vet.
GOOS / GOARCH: used for release asset names, platform-specific downloads, and build metadata.
GOCACHE / GOMODCACHE: still useful for custom cache workflows, restore-only caches, cross-job/shared caches, Docker volume mounts, Bazel configuration, sudo env forwarding, and cache cleanup/statistics.

Representative public examples from the sampling included workflows and actions in diggerhq/digger, magnetikonline/action-golang-cache, GoogleCloudPlatform/k8s-config-connector, smartcontractkit/.github, openziti/ziti, tuananh/actions, kubernetes-sigs/cluster-api, buildkite/agent, github/gh-aw, milvus-io/milvus, and numtide/go2nix.

My recommendation would be to treat the built-in cache as solving the default caching use case, but keep the Go environment output feature because it addresses a broader set of real-world workflow needs that are separate from caching.

Hello everyone👋,
Thank you all for the helpful feedback on this! Since setup-go already runs go env, most of the variables mentioned here are already part of that single command's output - for example GOPATH, GOBIN, and GOROOT.

We would like to know: would simply exposing the go env as output be enough to cover your use case, or would you specifically need each variable as separate named outputs such as GOPATH, GOBIN, GOROOT, GOTOOLDIR, GOOS / GOARCH, and GOCACHE / GOMODCACHE?

Your feedback would be really helpful in choosing the best approach. Thank you so much for your patience!

@bflad

Hi @bflad,

This has been implemented in #791, which exposes the go env variables as action outputs. You can now reference them directly from the setup-go step outputs instead of running go env manually.

You can try it out using actions/setup-go@main.

Closing as resolved.

Is there any reason why you expose these env vars as e.g. go-mod-cache rather than the original and well known GOMODCACHE? Having to remember what the kebab case form looks like seems unfortunate and inconsistent with the Go ecosystem.

@v-mahabaleshwars

@v-mahabaleshwars can we reconsider the casing of the env vars, as request by @mvdan? I do think it make sense names as outputted by go env rather than inventing our own convention?

I made the same suggestion back in 2023, for what it's worth :) #334 (comment)

@mvdan

Hello @mvdan and @qmuntal 👋,
Thank you for sharing your feedback! We understand that aligning with the original go env names would be more consistent with the Go ecosystem. We're working on renaming the outputs(GOPATH, GOBIN, GOROOT, GOTOOLDIR, GOOS / GOARCH, and GOCACHE / GOMODCACHE) accordingly and will share an update here once the change is in.
Thanks for your patience!

Thanks very much! Looking forward to testing it out once it's in a release.

From looking at https://github.com/actions/setup-go/blob/main/action.yml, two questions pop to mind:

Is go-version different from go env GOVERSION? If not, I would rename it. If it is, then I would document it very clearly to avoid confusion.
Similarly, it is unclear whether go-bin-path is different to GOBIN. Note that, since May 2026, Go has printed a default for go env GOBIN: cmd/go: default GOBIN to GOPATH[0]/bin when outside of GOPATH? golang/go#23439

If these are from older versions of setup-go, and hard to remove without breaking users, I'd suggest deprecating them so that the next major version of setup-go can remove them in favor of GOVERSION and GOBIN.

@mvdan

Hi @mvdan,

Thanks for the suggestion. go-version and GOVERSION identify the same toolchain, but the formats differ slightly: 1.24.11 versus go1.24.11. Workflows may rely on the unprefixed form, while the prefixed form matches Go's own version string.

go-bin-path is mainly a convenience for older toolchains: it uses GOBIN when non-empty, otherwise bin under the first GOPATH entry. On Go 1.27+ the outputs normally match; the fallback remains useful on Go 1.26, which is still supported upstream. We’ll update the docs accordingly.

@mvdan

Hi @mvdan,
The documentation concerns are addressed in #803.
Closing this issue as resolved.

Navigation Menu

Repository navigation

Support for Outputting or Exporting Go Environment Variables #54

Version

Description

11 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Support for Outputting or Exporting Go Environment Variables #54

Description

Version

Description

Activity

Sergey-Murtazin commented on Oct 19, 2021

jgustie commented on Oct 19, 2021

bflad commented on Oct 19, 2021

lucacome commented on Jul 23, 2022

qrkourier commented on Feb 15, 2023

lucacome commented on Feb 16, 2023

urica12 commented on Feb 16, 2023

mvdan commented on Mar 27, 2023

11 remaining items

qmuntal commented on Jun 12, 2026

v-priya-kinthali commented on Sep 11, 2026

v-mahabaleshwars commented on Sep 22, 2026

mvdan commented on Sep 22, 2026

qmuntal commented on Sep 22, 2026

mvdan commented on Sep 22, 2026

v-priya-kinthali commented on Sep 24, 2026

mvdan commented on Sep 28, 2026

mvdan commented on Sep 28, 2026

v-mahabaleshwars commented on Oct 7, 2026

v-mahabaleshwars commented on Nov 4, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions