Allow customized location of Go toolset

[shueybubbles]

Description:
Please add a parameter to actions/setup-go to enable a customized download location of the Go toolset.

Justification:
Microsoft is directing teams to build Go applications with the new Microsoft build of Go tools. Rewriting action yml to download and extract the Microsoft builds of Go will cost a lot of time across the organization. Centralizing this capability in the existing setup-go action will save time and money. Their base URLs are different from google's but the paths per-version are the same.

[dsame]

Hello @shueybubbles , thanks for the notifying us - we're going to address this issue in the near future.

[dagood]

I noticed https://go.dev/dl/?mode=json&include=all is being used here, and wanted to give a tip in case this is important: like most forks, we have a small delay between when official Go is available and Microsoft Go has the same version available, so if https://go.dev/dl/?mode=json&include=all is being used to determine which versions are available, it might not be enough to simply swap out the links. We also provide revision releases to fix issues specific to the Microsoft fork (1.20.6-1) that could interfere with caching logic depending on how that's handled.

Just recently we've put together a chain of links that can get to our latest builds:

• https://github.com/microsoft/go/blob/microsoft/main/eng/doc/release-branch-links.json has a list of aka.ms links that are updated to point at the latest build of each major version of Go we support on the day we release the Microsoft Go build.
• Downloading the manifest listed inside that file (like https://aka.ms/golang/release/latest/go1.20.assets.json) lists the permanent links for the latest version of 1.20.x as of that moment.
  • If you don't use the manifest and download the archive+checksum+signature aka.ms links directly, you could hit a race condition: grabbing https://aka.ms/golang/release/latest/go1.20.linux-amd64.tar.gz and https://aka.ms/golang/release/latest/go1.20.linux-amd64.tar.gz.sha256 on a release day could mean you end up downloading a tar.gz for 1.20.5 and a checksum for 1.20.6 if the timing's just right--and those wouldn't match up.

We don't have any repository of every version we've ever released, however, other than the Git tags on the microsoft/go repo. A link like go1.20.6.assets.json or go1.20.6-1.assets.json does work, but we don't have a list of all the possible links.

If this isn't enough to support microsoft/go in setup-go and something more directly similar to https://golang.org/dl/?mode=json and https://golang.org/dl/?mode=json&include=all is necessary to make this feasible, let me know. 🙂 It's in the realm of possibility for us to implement, it just doesn't match up with any of the infrastructure we currently have so it will take some time.

[dsame]

Hello @shueybubbles ,

I do not think it makes sense to provide Microsoft Go Tools as a part of the action because the main purpose of microsoft/go is to build FIPS 140-2 compliant applications, and this assumes the build tools must be managed by a developer and not by a 3rd party.

[dagood]

the build tools must be managed by a developer and not by a 3rd party.

Assuming this is the case (I haven't heard it before, and it doesn't seem to me like a distinction that can be made easily, if at all), then it would still be useful to run Microsoft Go in GitHub CI to make sure the application functions using OpenSSL/CNG even when external contributors are submitting PRs. Later, the program can be built again in internal systems for FIPS compliance.