-
Notifications
You must be signed in to change notification settings - Fork 1.1k
helm operator: support external helm repos #1131
Comments
Would be great if implemented ! |
Hi @davidkarlsen can you confirm if you've tried this successfully with subcharts? I tried it but I still had to check-in the downloaded chart into my repo. |
@ahmadiq I have not tried it with subcharts and I'd guess it would break / you'd need to hack it |
@ahmadiq I'll correct myself - yes it works with subcharts. The way I do it is with a hacky shellscript to suck down the charts and add them to my git-repo so that flux is happy:
that way charts are complete and checked in - including subcharts. |
+1 |
For me, this is the number one missing feature at the moment. |
Related thoughts: Was thinking about using a "charts" repo like https://github.com/kubernetes/charts for our own charts. This can work but would need to run two copies of the flux helm operator, one pointing at the official charts repo, and one pointing at our custom charts repo for our own applications. Could also be a valid use case to point at multiple chart repos, possibly a separate GH issue for that? |
The external Helm repos support has been implemented in this PR #1382 |
Oooh, thanks! I will take a look! |
That one seems merged - but still the issue is open? Is this usable - or are other parts required? |
Does this mean I can reference dependencies in requirements.yaml pointing to our own chartmuseum repo? And a |
Those assumptions are true with version I think the issue is still open because we do not support full authentication for registries yet in a easy way. But @squaremo should be able to tell you more. |
To use external repos that need authentication, you'll need to mount a I'm not sure how well our flux chart supports this at present, and anyway, it's a bit of a workaround. I've opened #1567 for implementing |
today flux/helm-operator is based on checking in the charts into the same git-repo as the yaml files declaring FluxHelmRelease resources.
It would be nice if instead the configuration could point at helm repositories (like for instance https://kubernetes-charts.storage.googleapis.com) - that way the helm chart repo can be centralized and reused.
Note to other people having the same problem: you can circumvent this by creating a subchart(https://github.com/kubernetes/helm/blob/master/docs/chart_template_guide/subcharts_and_globals.md) and refer the external repo through requirements.yaml and point to the external repo - but this is not optimal as it requires some scaffolding and also messes with the naming
The text was updated successfully, but these errors were encountered: