Skip to content
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

Does not handle non-standard versions #31

Open
lnhrdt opened this issue Oct 9, 2021 · 3 comments
Open

Does not handle non-standard versions #31

lnhrdt opened this issue Oct 9, 2021 · 3 comments

Comments

@lnhrdt
Copy link

lnhrdt commented Oct 9, 2021

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
Copy link
Member

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.

if (
semver.satisfies(releases[i].tag_name, version, {
includePrerelease: includePrereleases,
})

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
Copy link
Author

lnhrdt commented Oct 11, 2021

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants