bazel-contrib / bazel-contrib/rules_go

[feat] Support `GOPROXY` for Go SDK/toolchain downloads (via `golang.org/toolchain` module)

Open
#4,516 2 comments 0 reactions 0 assignees View on GitHub
Dominant language
Go
Stars
1.5k
Forks
760
Avg merge
1d 11h
Merged PRs (30d)
12

Description

*Disclaimer: Generated most of the body content using LLM / GenAI. Hope it's clear, open to feedback.*

**TLDR;** I would like `rules_go` to support downloading the Toolchain/SDK from `GOPROXY` as well. (and ideally even recognize the `toolchain` directive in the `go.mod` file.

If this makes sense, I will plan to send a patch.

### Problem Statement

Currently, `go_register_toolchains` fetches Go SDKs from a hardcoded URL template that defaults to `go.dev/dl` (e.g., `https://go.dev/dl/go1.25.0.linux-amd64.tar.gz`).

Many organizations prefer to source all build artifacts from an internal, trusted repository (like Artifactory, Nexus, Athens, etc.) that implements the `GOPROXY` protocol. While `rules_go` correctly uses `GOPROXY` for module dependencies, the SDK download mechanism is separate.

This forces users to implement and maintain separate workarounds for the Go SDK itself, such as:

1. **Mirroring:** Hosting all SDK `.tar.gz` variants on an internal HTTP server and passing a custom `urls` list.
2. **Downloader Configuration:** Maintaining a `bazel_downloader.cfg` file to intercept and rewrite the hardcoded `go.dev/dl` URLs.

Both solutions add maintenance overhead and are redundant when a fully capable `GOPROXY` is already in use for all other Go modules.

### Proposed Solution

The native Go command (since 1.21) can now fetch the toolchain as a standard Go module: `golang.org/toolchain`.

When `go get toolchain@go1.25.0` is run, the Go command resolves this to a platform-specific module version (e.g., `v0.0.1-go1.25.0.linux-amd64`) and fetches it as a `.zip` file from the configured `GOPROXY`.

`rules_go` could adopt this same "toolchain-as-a-module" fetching mechanism. This would allow the SDK to be downloaded using the same `GOPROXY` logic as all other module dependencies.

### Key Benefits

* **Reduces Maintenance:** Eliminates the need for a `bazel_downloader.cfg` or a separate HTTP mirror for Go SDKs.
* **Unifies Artifact Source:** Allows all Go-related artifacts (modules *and* the SDK) to be sourced from a single, trusted `GOPROXY`.
* **Aligns with Go Toolchain:** Leverages the modern, standard Go method for toolchain distribution, including proxy and checksum mechanisms.

### Potential Implementation

This could be exposed as a new attribute on `go_register_toolchains`, such as `download_method = "goproxy" | "http"`.

When `download_method = "goproxy"` is set, the rule would:
1. Resolve the `version` to the correct `golang.org/toolchain` module version for the host/target platform.
2. Use the existing `GOPROXY` logic (respecting `GOPROXY`, `GOSUMDB`, etc.) to fetch and unzip this module.
3. Use the contents as the Go SDK.

Contributor guide

Open the contributing guide

Research direction

Start at the go_register_toolchains download path and compare it with the existing GOPROXY handling for module dependencies. Review the proposed golang.org/toolchain module resolution for the host and target platform. Done means Go SDKs can be fetched and unpacked through GOPROXY, with the download method and toolchain version behavior defined.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
build-system
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
32/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.