-
Notifications
You must be signed in to change notification settings - Fork 521
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support Go version 1.18beta1
#177
Comments
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. Lines 51 to 62 in fdeec47
When trying to use
The second attempt to find the version is by running Lines 78 to 87 in fdeec47
It tries to find a match in the list of golang artifacts based on the provided version and the system architecture and platform. Lines 213 to 230 in 331ce1d
One culprit, at least when running the action on However, the official golang artifact list uses Maybe this helps somebody to provide a fix for this. |
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 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 |
As a workaround, just run your code inside Go container:
This way you don't need to setup go. |
@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. 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 👍 |
* Use Go 1.18 for CI * Use beta version of Go * Try a different syntax for beta version * Use syntax found in actions/setup-go#177
I'm glad that we could help you. I close this issue. |
Thanks everyone and @Sergey-Murtazin! The |
A recommendation for the future, it may be worth adding a note to the I was personally looking for the way to import the beta, and missed the "Matching an unstable pre-release" example adding said input. |
Description: Support
go-version
1.18beta1
(or have it as1.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.The text was updated successfully, but these errors were encountered: