feat: add go-download-base-url input for custom Go distributions

[gdams]

Description:

Add support for downloading Go from custom sources such as Microsoft build of Go (aka.ms). Users can specify a custom download base URL via the go-download-base-url input or the GO_DOWNLOAD_BASE_URL environment variable (input takes precedence).

When a custom URL is provided, the action skips the GitHub-hosted manifest and attempts to resolve versions from the custom URL's JSON listing. If the listing is unavailable (as with aka.ms redirect links), it falls back to constructing the download URL directly from the version, platform, and architecture.

Usage:

• uses: actions/setup-go@v6 with: go-version: '1.25' go-download-base-url: 'https://aka.ms/golang/release/latest'

Changes:

• action.yml: add go-download-base-url optional input
• installer.ts: add getInfoFromDirectDownload() for URL construction fallback, thread custom URL through getGo/getInfoFromDist/findMatch
• main.ts: read new input and GO_DOWNLOAD_BASE_URL env var
• setup-go.test.ts: add 12 unit tests for custom URL behavior
• microsoft-validation.yml: add E2E workflow testing Microsoft build of Go across ubuntu/windows/macos with versions 1.24 and 1.25
• README.md: document new input with Microsoft build of Go examples

Related issue:
#399

Check list:

• Mark if documentation changes are required.
• Mark if tests were added or updated to cover the changes.

[Copilot]

Pull request overview

Adds support for downloading Go toolchains from a user-specified base URL (via go-download-base-url input or GO_DOWNLOAD_BASE_URL env var), enabling custom/mirrored Go distributions such as the Microsoft build of Go.

Changes:

• Introduces a new optional go-download-base-url input and threads it through the installer logic.
• Adds custom-download behavior in the installer, including a “direct URL construction” fallback when a JSON version listing is unavailable.
• Expands unit tests and adds an E2E workflow validating Microsoft Go across OSes.

Reviewed changes

Copilot reviewed 6 out of 7 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
src/main.ts	Reads the new input / env var and passes it into the installer.
src/installer.ts	Implements custom base URL download flow, cache isolation (go-custom), and direct-download URL construction fallback.
dist/setup/index.js	Updates compiled distribution to include new logic and exports.
action.yml	Adds go-download-base-url input metadata.
tests/setup-go.test.ts	Adds unit tests for custom base URL behavior and fallback paths.
README.md	Documents the new input and provides usage examples.
.github/workflows/microsoft-validation.yml	Adds E2E workflow exercising Microsoft Go distribution scenarios.

Comments suppressed due to low confidence (1)

src/installer.ts:487

• getInfoFromDirectDownload() constructs the archive filename directly from versionSpec. If versionSpec is a range/alias (e.g. "1.25", "^1.25.0", "1.25.x"), this will generate a non-existent filename and can also lead to caching under a coerced version that doesn’t match what was downloaded. Consider validating that versionSpec is an exact Go version (optionally with a leading "go") before constructing the URL, and throw a targeted error telling users to provide an exact patch version when the JSON listing endpoint isn’t available.

export function getInfoFromDirectDownload(
  versionSpec: string,
  arch: Architecture,
  goDownloadBaseUrl: string
): IGoVersionInfo {
  const archStr = sys.getArch(arch);
  const platStr = sys.getPlatform();
  const extension = platStr === 'windows' ? 'zip' : 'tar.gz';
  // Ensure version has the 'go' prefix for the filename
  const goVersion = versionSpec.startsWith('go')
    ? versionSpec
    : `go${versionSpec}`;
  const fileName = `${goVersion}.${platStr}-${archStr}.${extension}`;
  const downloadUrl = `${goDownloadBaseUrl}/${fileName}`;

  core.info(`Constructed direct download URL: ${downloadUrl}`);

  return <IGoVersionInfo>{
    type: 'dist',
    downloadUrl: downloadUrl,
    resolvedVersion: versionSpec.replace(/^go/, ''),
    fileName: fileName
  };

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[priyagupta108]

Hi @gdams — thanks for the PR! This is a valuable addition.

It currently shows merge conflicts. Could you please rebase/merge the base branch (main) and resolve the conflicts?

Also, could you take a look at the Copilot feedback already left on the PR? Please incorporate the suggestions, or reply on the threads if you’d prefer not to change something.

We tested this change and found a few issues/improvements to address:

1) Toolcache version key mismatch when the input is major/minor
What we observed in logs:

• Input: go-version: 1.20, go-download-base-url: https://aka.ms/golang/release/latest
• The action constructs a URL using go1.20.<os>-<arch>...
• It caches the install under a directory derived from the input (1.20 → 1.20.0):
  • Successfully cached go to /opt/hostedtoolcache/go-custom/1.20.0/x64
• But the actual installed version is a patch release:
  • go version go1.20.14 linux/amd64

So the toolcache directory reflects the input spec, while the installed Go is a different patch version. This is confusing and may lead to surprising reuse if the upstream “latest patch” changes. Ideally we should cache under the actual installed patch version, or at minimum warn/document this behavior when users provide only major/minor.

Screenshot below highlights the input version (1.20), the derived toolcache directory (1.20.0), and the actual installed patch version (go1.20.14) from the same run:

2) Reduce duplicate logging of the custom base URL
The custom base URL is logged both in src/main.ts and again in src/installer.ts. It’s not wrong, but it’s noisy and repeats the same information. Could we keep it in one place?

Screenshot below captures the duplicate go-download-base-url log lines, showing where the custom base URL is printed more than once:

3) Clarify check-latest behavior when a custom download base URL is set
The custom base URL path doesn’t resolve “latest” the same way as the default manifest-based behavior. Could you add/adjust a note in README.md explaining what check-latest does (and does not do) when go-download-base-url is provided?

4) Fail gracefully when binaries aren’t available for the requested OS/arch
If the custom source doesn’t provide a binary for the requested platform/arch (e.g., go-version: 1.25.0 on windows/arm64, or a mirror missing artifacts), the workflow can fail with hard-to-understand errors, so it should instead fail with a clear, actionable message that includes the platform/arch and the exact download URL that was attempted.

5) Clarify unsupported version format (custom go-download-base-url)
When go-download-base-url is set, the action may fall back to constructing the download URL directly from the provided go-version. In that direct-URL path, version specifier/range syntax and pre-release identifiers don’t map cleanly to an artifact filename (e.g., ^1.25.0, ~1.25, >=1.25.0 <1.26.0, 1.25.0-rc.1).

Please document in the README which go-version formats are supported with go-download-base-url (especially in the direct-URL fallback case), or add support if broader version spec formats are intended. Also ensure unsupported formats fail with a clear, actionable error.

Screenshot below shows the exact error output when go-version is set to ^1.25.0 and the action falls back to constructing the direct download URL:

6) Access token support for custom download base URL
If go-download-base-url points to an authenticated/private mirror, downloads may require credentials. It would be helpful to support an optional access token input for the custom download flow.

Thanks again—happy to re-test once updates are pushed.

[gdams]

@priyagupta108 thanks for your feedback, I've made all the requested changes