Feature Request: Support all the post-render strategies available in the Helm SDK

[matheuscscp]

⚠️ Breaking change: From Flux 2.8.0 to 2.8.5 the default was combined (Helm 4 breaking change), then in Flux 2.8.6 we fixed the regression (changed the behavior to nohooks). In Flux 2.9 (via #1470) we are changing this default back to combined for honoring the feature gate UseHelm3Defaults, which defaults to the Helm 4 defaults when the gate is false, and to the Helm 3 defaults when the gate is true. We are sustaining our decision to keep aligned with Helm's defaults throughout Flux's and Helm's lives. This commitment implies shipping breaking changes whenever Helm changes default functionality in major versions.

The behavior can also be pinned to a specific value directly in the HelmRelease object through the field introduced in #1470.

Helm 4.2 will introduce 3 post-render strategies (see helm/helm#31985 and helm/helm#32049):

• nohooks: Helm 3 behavior, hooks are not sent to post-renderers. (this is Flux's behavior in >=2.8.6 <2.9.0, which was broken in >=2.8.0 <2.8.6)
• combined: Helm 4's default behavior, both hooks and templates are sent to post-renderers in the same stream. (this was the broken behavior in Flux >=2.8.0 <2.8.6)
• separate: Opt-in from Helm 4.2, hooks and templates are sent to post-renderers in separate streams.

I propose we introduce HelmRelease.spec.postRenderStrategy as an enum matching the 3 values defined by Helm, then in the install and upgrade actions this value can be passed to the SDK. The default should be nohooks, which is the current behavior in Flux >=2.8.6 <2.9.0.

[vocarista]

Hi @matheuscscp, I’d like to take this up.

From what I understand, this involves introducing HelmRelease.spec.postRenderStrategy to mirror Helm 4.2’s strategies (nohooks, combined, separate), defaulting to nohooks to preserve Flux’s current behavior.

One clarification: is nohooks intended purely as a backward-compatibility default for Flux, or are there specific considerations (e.g. kustomize handling of resources sharing the same FQN) that make it the preferred default longer-term?

Happy to start working on this once aligned.

[matheuscscp]

That's a great question. I think it's just a backward-compatibility default. I think the best option is combined, the current Helm CLI behavior. We are actually not respecting the UseHelm3Defaults feature gate now... Maybe we should change to combined as the default in Flux 2.9, and then switch to nohooks as the default if the gate is enabled. I think it's fair that we made the 2.8 default the backwards-compatible one since we did not provide the new field we will ship in 2.9. But we should stick to our decision of aligning with Helm's defaults.

@stefanprodan Thoughts?

[vocarista]

I've opened a PR for this issue and made the default value conditional on the UseHelm3Defaults gate. Let me know if you want any changes to the approach.