Does not handle non-standard versions

[lnhrdt]

I've been trying to use engineerd/configurator to install the latest version of kubernetes-sigs/kustomize, following the example given for kubernetes-sigs/kind.

kind github release versions follow the expected convention (e.g. v0.11.1) however kustomize github release versions contain the name of the binary as well (e.g. kustomize/v4.4.0). I've found that both the {{version}} and {{rawVersion}} template variables contain values like kustomize/v4.4.0 and as such I've been unable to construct a proper urlTemplate.

How can I use this action to download releases like kustomize that have more complex version number formats?

[radu-matei]

Oh, version numbers... Yeah, the assumption is that the release names follow semver (adjusting for a leading v before the version number), and as you found out, kustomize/v4.4.0 is just not a valid semver version or constraint. Unfortunately, you are not going to be able to use the current version of the action to download from GitHub releases for versions that are not valid semver.

https://github.com/engineerd/configurator/blob/94e10ecef5d996565e35a78795802d8bd86f8fb2/src/release.ts#L88-L91

That being said, you can pin to a specific version and use the download URL directly (similar to other examples in there for Helm or Kind). I realize it's not ideal that you have to pin to a specific version and manually update it.

I'm happy to discuss refactoring the way we check for version constraints.

[lnhrdt]

I'm happy to discuss refactoring the way we check for version constraints.

The only idea that comes to mind for me would be adding an optional input called versionPrefix that defaults to v but can be overridden to something else (e.g. kustomize/v in my case).

It's hard for me to say if this is a good design for many users in general, or for just me in this particular scenario. However I have seen the same convention for other projects that release multiple products/binaries. Thoughts?

[radu-matei]

There are two main things to keep in mind here:

• searching for a satisfying version constraint needs a valid semver
• searching for a satisfying release name needs to follow the project’s naming conventions.

There is one more option I should have mentioned that would allow you to always keep the version up-to-date, and that is using latest. It does not check anything, and will always download the latest release, so use it with caution as it might break your workflow if the tool has breaking changes.