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

Possibility to repackage a chart or specify additional values/images in helm_install rules #11

Open
recons opened this issue Nov 3, 2022 · 3 comments
Labels
question Further information is requested

Comments

@recons
Copy link

recons commented Nov 3, 2022

First of all, thank you for the great library!
I want to use it in my project, but i'm not sure how to handle a case when I need to import a chart from repository and install it with additional values file and docker image dependency.
More specifically, I want to import a bitnami kafka chart and provide additional initContainers and change heap opts.
First possible workaround, which comes to my head, is to import a chart by http_archive rule and then package it with helm_package rule. Is there any way to do it better?

@abrisco
Copy link
Owner

abrisco commented Nov 5, 2022

Thanks! and thanks for trying out the Bazel rules!

Your workaround is what I would have done though I'm also not sure if that's the best way. How would this work without Bazel? Is there an existing workflow you have that you're just trying to port over?

Also, there's helm_import_repository which you could use to import charts from a registry. The docs there are a bit lacking but I have an example of using it here: https://github.com/abrisco/rules_helm/blob/0.0.3/tests/test_deps.bzl

@abrisco abrisco added the question Further information is requested label Nov 5, 2022
@recons
Copy link
Author

recons commented Nov 6, 2022

How would this work without Bazel?

I'd push dependent image to the registry first and then install a chart with additional values like this

helm repo add bitnami https://charts.bitnami.com/bitnami
helm install kafka bitnami/kafka -f values.yaml

From my perspective, providing additional values(and images) to helm_install rule is actually missed in current implementation

Is there an existing workflow you have that you're just trying to port over?

Yes, currently I use another library, but it's very limited in the process of resolving images(I could pass only 1 image there), so I decided to try something else.

Also, there's helm_import_repository which you could use to import charts from a registry.

Yes, that's exactly what I want to use to install a chart later with additional values/images.

P.S. I think there should be also a way to provide a namespace(with the possibility to create it) via helm install. Usually, we don't hardcode it in a chart.

@abrisco
Copy link
Owner

abrisco commented Nov 14, 2022

Sorry for the delay!

I'd push dependent image to the registry first and then install a chart with additional values like this

helm repo add bitnami https://charts.bitnami.com/bitnami
helm install kafka bitnami/kafka -f values.yaml

From my perspective, providing additional values(and images) to helm_install rule is actually missed in current implementation

You can pass arguments to helm install using a command like the folling bazel run //my:install -- --help. But I would agree it would be nice to allow helm_install to have some values attribute you can use as an equivalent to the command you posted. I can try to add something like this when I get a moment but would also be happy to review a PR if you wanted to submit one.

P.S. I think there should be also a way to provide a namespace(with the possibility to create it) via helm install. Usually, we don't hardcode it in a chart.

Sounds reasonable to me. Could definitely see a namespace attribute being added. Do you wanna make a new issue for this and I can try to get to it too? (Again, happy to review a PR too 😅)

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

No branches or pull requests

2 participants