-
Notifications
You must be signed in to change notification settings - Fork 46
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
feat: add support for helm compatible binaries like werf #211
Conversation
removing brittle helm binary check
Thank you for the contribution. I think you'll have to change all references from
and call it with |
@aslafy-z for werf, you don't use And yes I understand that there might be a use-case for multi-worded executables especially to not have to write a script, however, that's not really what I'm trying to target here, primarily because it increases my test surface (what about HELM_BIN='do_x && helm') as you rightly pointed out. I'll be happy to create a separate issue for multi word support in HELM_BIN to look for use-cases in the community. |
@himanshu-garg-razorpay lgtm! Can you please rebase your PR before I merge it? Thank you |
@aslafy-z Done. Please go ahead. |
@aslafy-z thanks for the approval and running the workflows. The workflow checks have passed. Shall we merge this now..? |
@aslafy-z if there's nothing else already planned to be released (not seeing any open PRs), please create a new release so that we can start deprecating our internal fork |
🎉 This PR is included in version 0.13.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
@himanshu-garg-razorpay the release pipeline was stuck for some reason. It should be good by now 🚀 |
What's in this PR?
Removes the code checking for the "validity" of the helm binary provided.
It was a brittle mechanism grepping for the current documentation on calling help.
This breaks not just for different helm compatible binaries like werf but also if helm itself changes its documentation.
The "validity" of a binary is hard to define in a way that allows interop with all future helm compatible binaries.
Also, I don't think we'll introduce any bugs by not checking this because when someone passes an "invalid" binary it will just not work. On the other hand, if it works, who are we to say it's not a valid binary. If it walks like a duck, quacks like a duck, it is a duck.
Checklist