-
Notifications
You must be signed in to change notification settings - Fork 510
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
Parse .tool-versions file to determine Go version #376
Conversation
d |
dddjdk |
Is there a particular reason why ASDF handling is being introduced into various actions rather than introducing an ASDF-specific action which parses and outputs per-tool version information? e.g. In psuedo-workflow configuration: - uses: actions/checkout
- uses: xxx/read-asdf
id: asdf
- uses: actions/setup-go
with:
go-version: steps.asdf.outputs.go This enables downstream actions to remain generic within their domain, rather than needing to understand and maintain a different tooling ecosystem. |
Another potential consideration is the
This is something else that could be handled once in an upstream action, rather than leaving the burden on any downstream actions to figure out the solution or potentially ignore the feature. |
@bflad A good question. I could see a version parser being added as a separate action. My argument is that it's being added to a lot of other actions across the language ecosystem so why not add here as well. ASDF does provide an action for installing all the things, but it doesn't (and arguably shouldn't) take into account all the potential dependency caching mechanisms most of these language-specific libraries add. I could definitely look to add a tool version output parser to the ASDF action as well, but I'd still see value in this addition. I believe ASDF is attempting to put forward a tool agnostic version spec file (as opposed to a |
relates to #375 |
Closing in favor of #402 |
hi |
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.