-
Notifications
You must be signed in to change notification settings - Fork 262
Expose post-renderer as part of a HelmRelease install #365
Comments
I was planning on suggesting this same feature. My vote is for post renderer option to use a custom image defined through a simplified job template. Then no change to Fluxcd/helm-operator is needed and we would simply define an arbitrary job with whatever image. Then Fluxcd/helm-operator would implement it's own post-render which runs the job described in the HelmRelease postRenderer. With our own custom images/jobs it would be very easy to experiment and do very custom things without having to redeploy or alter helm-operator in any way. I was imagining something like: apiVersion: helm.fluxcd.io/v1
kind: HelmRelease
metadata:
name: rabbit
namespace: default
spec:
postRender:
image: my-custom/kustomize:latest
cmd: ./patch.sh
... # the rest of the job template like volumes and env vars
chart:
name: rabbitmq
...
values:
replicas: 1
... |
Yes please! This would be amazing and simplify some chart scenarios. |
Please support this. |
@codejamninja This project is now in maintenance mode, I created a new issue in the new project: fluxcd/helm-controller#104 |
Sorry if your issue remains unresolved. The Helm Operator is in maintenance mode, we recommend everybody upgrades to Flux v2 and Helm Controller. A new release of Helm Operator is out this week, 1.4.4. We will continue to support Helm Operator in maintenance mode for an indefinite period of time, and eventually archive this repository. Please be aware that Flux v2 has a vibrant and active developer community who are actively working through minor releases and delivering new features on the way to General Availability for Flux v2. In the mean time, this repo will still be monitored, but support is basically limited to migration issues only. I will have to close many issues today without reading them all in detail because of time constraints. If your issue is very important, you are welcome to reopen it, but due to staleness of all issues at this point a new report is more likely to be in order. Please open another issue if you have unresolved problems that prevent your migration in the appropriate Flux v2 repo. Helm Operator releases will continue as possible for a limited time, as a courtesy for those who still cannot migrate yet, but these are strongly not recommended for ongoing production use as our strict adherence to semver backward compatibility guarantees limit many dependencies and we can only upgrade them so far without breaking compatibility. So there are likely known CVEs that cannot be resolved. We recommend upgrading to Flux v2 which is actively maintained ASAP. I am going to go ahead and close every issue at once today, |
Describe the feature
The post renderer feature was introduced in Helm 3.1.0 and allows for some really powerful chaining of tools together. For example, one can install a Helm chart and pipe the output to
kustomize
to apply a label transformer or add a secret/configMap generator.It would be awesome if the helm-operator could accept an arbitrary command that can be executed as post-renderer by the operator after Helm renders out templates from a chart.
What would the new user story look like?
A custom annotation as an experimental feature?
An explicit field on the
HelmRelease
custom resource?Expected behavior
Either in the helm-operator image or through a custom image, allow an arbitrary string to be passed to the
--post-renderer
argument during the Helm install/upgrade step of theHelmRelease
resource. Whitelist executables so only trusted binaries are allowed (such askustomize
) or allow users to use their own helm-operator image with their own executables.The text was updated successfully, but these errors were encountered: