feat(manager/asdf): add additional asdf supported tools

[maennchen]

Changes

Adds support for the following tools to the asdf manager:
awscli, bun, cargo-make, clojure, crystal, deno, direnv, dprint, elixir, elm, erlang, gauche, golang, haskell, helmfile, helm, hugo, idris, java, julia, just, kotlin, kustomize, lua, nim, nodejs, ocaml, perl, php, python, ruby, rust, scala, shellcheck, shfmt, terraform, trivy, zig

Context

Currently, only nodejs is supported.

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please tick one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests but ran on a real repository, or
• Both unit tests + ran on a real repository

Test Repo: https://github.com/jshmrtn/renovate-asdf-test

Code is largely extracted from:
https://github.com/kachick/renovate-config-asdf/tree/1.8.0/plugins

Thanks @kachick!

[rarkins]

LGTM

[multani]

At least these tools are fetched from GitHub releases: using the GitHub tag can create a race condition where the tag has been published but not the release yet, which will fail asdf it the update is merged.

I implemented these on @kachick repository and that was an oversight from me, if we can have the fixed version here, that would be great!

[viceice]

At least these tools are fetched from GitHub releases: using the GitHub tag can create a race condition where the tag has been published but not the release yet, which will fail asdf it the update is merged.

I implemented these on @kachick repository and that was an oversight from me, if we can have the fixed version here, that would be great!

sounds good. we should use releases when they are used by those tool instead of git tags

[multani]

At least these tools are fetched from GitHub releases: using the GitHub tag can create a race condition where the tag has been published but not the release yet, which will fail asdf it the update is merged.
I implemented these on @kachick repository and that was an oversight from me, if we can have the fixed version here, that would be great!

sounds good. we should use releases when they are used by those tool instead of git tags

Yes, I guess it could be applied to other tools, but it's probably plugin dependent, so in theory, it should be configured on a case by case basis ...

[multani]

I had a look at all the links posted and make further adjustments.

Otherwise, this looks great!

Worst case scenario:

• The config references a git tag instead of a release: there may be a slight race condition and the new version can't be downloaded, but I guess it really happens for a short time.
• The config references a GitHub Release but only git tags are published: no updates will be proposed and Renovate's own config will have to be fixed. No harms done, bugs happen :)

Also, this is really tied up to the current implementation of each plugin and how upstream packages are released, so 🤷

Thanks a lot for importing all of this!

[maennchen]

@viceice I added the tests 👍

[viceice]

next time you should open the PR from personal repo, otherwise we can't update your branch, with is needed for merge

[maennchen]

@viceice Would you prefer for me to open a new PR from my personal account to replace this one?

[viceice]

no, just use the github update button, and hope we get this merged fast enough before next main branch commit

[renovate-release]

🎉 This PR is included in version 34.25.0 🎉

The release is available on:

• GitHub release
• 34.25.0

Your semantic-release bot 📦🚀