Support Go version 1.18beta1

[qdm12]

Description: Support go-version 1.18beta1 (or have it as 1.18.0-beta1/1.18.x)

Justification: We want to experiment with Go 1.18 beta1 fuzzing and generics features, and it adds extra bloat in our CI configuration to install Go 1.18beta1 for now.

Are you willing to submit a PR? No; I have looked a bit through the code but it looks like something would need to be added to the go-versions repository which we cannot create PRs to.

[skaldarnar]

I'm in a similar situation and did some digging in the code. Here's what I found:

The lookup in the manifest of actions/go-versions is only the first attempt for finding a release. It looks like the manifest only contains stable releases, so we'll naturally fall back to the second option.

setup-go/src/installer.ts

Lines 51 to 62 in fdeec47

	//
	// Try download from internal distribution (popular versions only)
	//
	try {
	info = await getInfoFromManifest(versionSpec, stable, auth);
	if (info) {
	downloadPath = await installGoVersion(info, auth);
	} else {
	core.info(
	'Not found in manifest. Falling back to download directly from Go'
	);
	}

When trying to use 1.18beta1 (or go1.18beta1) I can find the log output I'd expect here:
Edit: the actual correct input for the version is 1.18.0-beta1, see #177 (comment).

Not found in manifest.  Falling back to download directly from Go

The second attempt to find the version is by running getInfoFromDist which in turn calls findMatch in installer.ts.

setup-go/src/installer.ts

Lines 78 to 87 in fdeec47

	//
	// Download from storage.googleapis.com
	//
	if (!downloadPath) {
	info = await getInfoFromDist(versionSpec, stable);
	if (!info) {
	throw new Error(
	`Unable to find Go version '${versionSpec}' for platform ${osPlat} and architecture ${osArch}.`
	);
	}

It tries to find a match in the list of golang artifacts based on the provided version and the system architecture and platform.

setup-go/src/installer.ts

Lines 213 to 230 in 331ce1d

	core.debug(`check ${version} satisfies ${versionSpec}`);
	if (
	semver.satisfies(version, versionSpec) &&
	(!stable || candidate.stable === stable)
	) {
	goFile = candidate.files.find(file => {
	core.debug(
	`${file.arch}===${archFilter} && ${file.os}===${platFilter}`
	);
	return file.arch === archFilter && file.os === platFilter;
	});
	if (goFile) {
	core.debug(`matched ${candidate.version}`);
	match = candidate;
	break;
	}
	}

One culprit, at least when running the action on ubuntu-latest, is that the architecture string cannot match.
The call to sys.getArch() yields "x64" which matches with the specification given in the manifest file, see

https://github.com/actions/go-versions/blob/9d9bd2c789e30036e2f05c4f3022de47e15b557e/versions-manifest.json#L13-L18

However, the official golang artifact list uses "amd64" as identifier.

Maybe this helps somebody to provide a fix for this.

[skaldarnar]

Update: I've got this working in a crude setup. Here's what I'm using right now:

I'm trying to build my little gh extension https://github.com/skaldarnar/gh-terasology with go1.18beta1.

https://github.com/skaldarnar/gh-terasology/blob/929a5be0db78e186214749ae42b935497da24c20/.github/workflows/release.yml#L14-L17

Therefore, I'm using a fork of https://github.com/cli/gh-extension-precompile to allow the usage of unstable releases. See cli/gh-extension-precompile@trunk...skaldarnar:trunk for the changes.

That in turn uses a fork of https://github.com/actions/setup-go with a crude fix to hard-code the mapping from "x64" to "amd64". See main...skaldarnar:main for the respective changes.

Not sure whether those changes are going in the right direction, though.

---

Somewhat related discussion about version handling in #63

[acim]

As a workaround, just run your code inside Go container:

    runs-on: ubuntu-latest
    container: golang:1.18-rc-bullseye
    steps:
        ...

This way you don't need to setup go.

[Sergey-Murtazin]

Hi, @qdm12!

I couldn't reproduce your problem.
Please check my WF.

I use

uses: actions/setup-go@v2
with:
  stable: 'false'
  go-version: '1.18.0-beta1'

Could you please provide some repro steps or public repo where your problem occurs?

[skaldarnar]

@acim @Sergey-Murtazin thanks for your suggestions and for testing this again.

It indeed seems that just using the right way to specify the version does the job.
Looks like the "x64" vs "amd64" part was misleading, and the actual issue was not writing the version number as it should be.

I just now saw that there is an explanation of the supported version syntax, but I did not get reading past the V2 section 🙈

I was able to make another test run on skaldarnar/gh-terasology@b541c5f without my hacky workaround and it worked just fine 👍
Sorry for all the fuzz here, no open questions or issues from my side.

[Sergey-Murtazin]

I'm glad that we could help you.

I close this issue.
Feel free to contact us if you have any questions.

[qdm12]

Thanks everyone and @Sergey-Murtazin! The stable: false field fixed it 👍

[deefdragon]

A recommendation for the future, it may be worth adding a note to the Supported version syntax section of the readme that unstable versions need stable: false. Or potentially adding an inputs table with both the format information and the stable input described.

I was personally looking for the way to import the beta, and missed the "Matching an unstable pre-release" example adding said input.