setup-go

repository·main·Indexed 23 days ago

https://github.com/actions/setup-go

A GitHub Action that sets up a Go environment for workflows. It handles downloading Go versions, managing toolchain directives, and provides built-in caching for Go modules and build outputs. It supports version resolution via specific versions, SemVer ranges, aliases (stable, oldstable), and version files such as go.mod, go.work, .go-version, and .tool-versions.

Tokens
7.3K
Snippets
22
Records
39
Agent score
81%

What's inside setup-go

  1. How Go version resolution works

    main

    The action resolves the requested version using the following priority order:

    1. Local cache: Checks the local tool cache for a matching semver version.
    2. go-versions repository: If not in the local cache, it pulls the version manifest from the main branch of the actions/go-versions repository.
    3. Direct download: If the lookup fails, it falls back to downloading directly from the official Go distribution site.

    Note: The action uses executable binaries built by the Go team and does not build Go binaries from source code.

  2. Configure caching for Go modules and build outputs

    main

    The action provides built-in caching for Go modules and build outputs using toolkit/cache. Caching is enabled by default (cache: true).

    • Default behavior: The action looks for go.mod in the repository root and uses its hash as part of the cache key.
    • Custom dependency path: If you have multiple dependency files or they are in subdirectories, use the cache-dependency-path input. This input supports glob patterns.
    • Disabling cache: Set cache: false to disable caching.

    If caching fails, the action logs a warning and continues the workflow execution.

    - uses: actions/setup-go@v7
      with:
        cache: true
        cache-dependency-path: 'go.sum'
  3. Contribute code to setup-go

    main

    Code contributions require the inclusion of relevant tests. Pull requests without tests may be held until tests are provided, unless maintainers deem them unnecessary or too burdensome.

    Development Workflow:

    • Use a "feature branch" for all changes.
    • Check for existing PRs covering your changes.
    • Link related issues in the Related issue: section of your PR.
    • Crucial: You must run the build script after making changes to transpile source code to javascript using NCC; otherwise, changes will not be included in the final build.
    • Ensure all tests pass before submitting.

    Available Scripts:

    • pre-checkin: Runs formatting, linting, building, and testing in a single command.
    • format: Ensures code complies with the project's code style.
    • lint:fix: Lints the code.
    • build: Transpiles source code to javascript (required after changes).

    Testing:

    • Unit tests: Located in the __tests__ folder.
    • End-to-end tests: Located in the workflows folder (e.g., .github/workflows/versions.yml).
    • Tests should cover successful execution, edge cases, and potential errors.

    Post-Submission:

    • CI checks will run automatically. Ensure all checks pass.
    • Maintainers will review the PR. If changes are requested, evaluate them critically before re-submitting.
  4. Configure caching for multi-target builds

    main

    To avoid reusing caches across incompatible builds (e.g., different OS or architecture), include files that capture build settings like GOOS or GOARCH in the cache-dependency-path. This ensures separate caches per target platform.

    env:
      GOOS: ...
      GOARCH: ...
    
    steps:
      - run: echo "$GOOS $GOARCH" > env.txt
    
      - uses: actions/checkout@v7
      - uses: actions/setup-go@v7
        with:
          go-version: '1.25'
          cache-dependency-path: |
            go.sum
            env.txt
      - run: go run hello.go    
  5. Review pull requests

    main

    Reviewing pull requests is a way to help maintain quality and support contributors.

    How to review:

    • Navigate to the pull requests tab.
    • Ensure you are familiar with the code or documentation being updated (except for minor changes like spelling).
    • Use GitHub's review functionality to ask clarifying questions, point out errors, or suggest alternatives.
    • Submit your review as a comment, an approval, or a request for changes.
    • Be respectful and kind to contributors. Distinguish between "nitpicks" (minor suggestions) and actual blockers to merging.
  6. Specify Go version using `go-version-file`

    main

    Instead of hardcoding a version, you can point setup-go to a version file. The action supports go.mod, go.work, .go-version, and .tool-versions files.

    Precedence: If both go-version and go-version-file are provided, go-version takes precedence.

    Behavior for go.mod:

    • It uses the toolchain directive if present; otherwise, it falls back to the go directive.
    • If the go directive omits the patch version (e.g., go 1.25), the action searches for the latest patch in the cache, then the versions-manifest.json, then the official Go website.
    # Read from go.mod
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-go@v7
        with:
          go-version-file: 'path/to/go.mod'
      - run: go version
    
    # Read from .go-version
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-go@v7
        with:
          go-version-file: '.go-version'
      - run: go version
    
    # Read from .tool-versions (asdf standard)
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-go@v7
        with:
          go-version-file: '.tool-versions'
      - run: go version
    
    # Read from go.work
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-go@v7
        with:
          go-version-file: 'go.work'
      - run: go version
  7. Recommended permissions for `setup-go`

    main

    To ensure proper functionality (such as checking out code and installing dependencies), it is recommended to set the following permissions in your workflow:

    permissions:
      contents: read
  8. Provide support on issues

    main

    You can contribute by helping users resolve questions in the issue tracker.

    Best Practices:

    • Only respond to issues you are confident you can answer accurately.
    • Refer to past issues with accepted answers and link to them in your replies.
    • Be kind and patient with users.
    • Once a discussion is resolved, ask the original filer or a maintainer to close the issue.
    • If a user violates the Code of Conduct, follow the Enforcement section of the Code of Conduct.
  9. Setup a Go environment in GitHub Actions

    main

    Use actions/setup-go@v7 to set up a Go environment. This action can download and cache a specific Go version, add it to the PATH, cache Go modules and build outputs, and register problem matchers for error output.

    Basic Usage:

    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-go@v7
        with:
          go-version: '1.25'
      - run: go run hello.go
  10. Use `stable` and `oldstable` aliases

    main

    You can use aliases to resolve Go versions:

    • stable: Resolves to the latest stable version from the go-versions manifest.
    • oldstable: Resolves to the latest patch release of the previous stable Go minor version (e.g., if 1.25.x is stable, oldstable resolves to 1.24.x).

    Note: Using these aliases is equivalent to setting check-latest: true with the corresponding minor version.

    # Use latest stable
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-go@v7
        with:
          go-version: 'stable'
      - run: go run hello.go
    
    # Use latest oldstable
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-go@v7
        with:
          go-version: 'oldstable'
      - run: go run hello.go
  11. Use restore-only caches for parallel builds

    main

    To reduce cache writes and avoid race conditions during parallel builds, you can disable automatic caching in setup-go and use actions/cache/restore manually. This allows you to create the cache in one specific build and simply restore it in others.

    jobs:
      build:
        runs-on: ${{ matrix.os }}
        strategy:
          matrix:
            os: [ubuntu-latest, macos-latest, windows-latest]
        steps:
          - uses: actions/checkout@v7
          - name: Setup go
            id: setup-go
            uses: actions/setup-go@v7
            with:
              go-version: '1.25.5'
              cache: false
          # ... (manual steps to set env vars and restore via actions/cache/restore@v5) ...
  12. Specify a Go version using `go-version`

    main

    Use the go-version input to define which Go version to install. You can provide an exact version for repeatable builds, a major/minor version to use the latest patch, or pre-release versions (beta/RC).

    Note: Specifying an exact patch version (e.g., 1.25.5) may increase setup time if that specific version is not already pre-installed on the runner. Using just a major/minor version (e.g., 1.25) is faster as it leverages pre-installed versions on the runner.

    # Exact version for repeatable builds
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-go@v7
        with:
          go-version: '1.25.5'
      - run: go run hello.go
    
    # Major/minor version (uses latest patch)
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-go@v7
        with:
          go-version: '1.25'
      - run: go run hello.go