Parse .tool-versions file to determine Go version #376
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description:
Allow
setup-go
to leverage the.tool-versions
file for determining the Go version desired. As noted in the linked issue belowRelated issue:
#375
Check list:
Please discuss:
This change currently makes .tool-versions the backup/fallback option if no other version spec is given. Is that desired?
ASDF/
.tool-versions
requires a fairly verboase version pattern which may or may not meet current version expectations. I see that there are a few cannonican version parsing strategies in the codebase here. Should the version be passed through those parsers or will the.tool-versions
version spec be adequate?I'm also unsure if the current default to
.tool-versions
path is going to be at project root. This is honestly my first attempt at contributing to a GH action codebase. I'd appreciate any "best practice" guidance availableASDF also accepts the following version formats:
ref:v1.0.2-a
orref:39cb398vb39
- tag/commit/branch to download from github and compilepath:~/src/elixir
- a path to custom compiled version of a tool to use. For use by language developers and such.system
- this keyword causes asdf to passthrough to the version of the tool on the system that is not managed by asdf.I'm not sure if any of these make sense to support given that this action currently only otherwise supports semver versions of the language.