Helm Provider Upgrade to 3.0.1 Introduces Unexpected Behavior with postrender, Namespace Resolution and Version Drift

[sujith1594]

Terraform, Provider, Kubernetes and Helm Versions

Terraform version: 1.9.8
Provider version: 3.0.1
Kubernetes version: 1.31

Issue 1: Postrender Attribute Causes Revisions and Chart Failures

We have upgraded the Terraform Helm Provider from 2.17.0 to 3.0.1.Updated the helm_resource block with all the breaking changes. After the upgrade, all Helm charts show a planned update in terraform plan with below change even though there are no changes in chart configuration.

 - postrender                 = {
          - args        = [] -> null
          - binary_path = "" -> null
        } -> null

Applying this causes unnecessary new revisions and in some cases, pods restart.
To mitigate this, we added a lifecycle rule to ignore the postrender attribute. That suppresses the diff as expected.
However, on making a valid change and reapplying, we receive this error:

Error: Error creating post-renderer
Could not create post-renderer: unable to find binary at : exec: "":
executable file not found in $PATH

Issue 2: Helm Behavior Changed When Templates Lack Explicit Namespace

In our setup, Terraform Enterprise runs in an EKS cluster and the tfe runs happen in the "tfe-dev-agents" namespace. After the upgrade, charts that do not explicitly declare "metadata.namespace" in their template manifest are:

Being deployed into the namespace specified in the helm_release block as expected.

However, their internal resources (e.g., from hooks or templates) are trying to deploy in "tfe-dev-agents", resulting in errors like:

Upgrade failed: namespaces "tfe-dev-agents" not found

This namespace doesn't exist in the target cluster, and we do not want to create it there. This behavior did not exist in v2.17.0 and seems tied to how the provider now resolves default namespaces.

Issue 3: Version Attribute Shows Diff for few charts

 ~ version = "0.5.1" -> "v0.5.1"
 ~ version = "v1.15.3" -> "1.15.3"

This seems to be a formatting difference, but causing unnecessary drift in plan output.

Please let us know how these issues can be addressed.

Thanks,
Sujith

[jaylonmcshan19-x]

Hi @sujith1594 We've just released a patch version v3.0.2 of the Helm Terraform Provider which includes a fix for this problem.
We'd really appreciate it if you could try it out and confirm whether this resolves the issue for you. If you still encounter any problems, feel free to follow up here and we’ll take another look.

Thanks again for your patience and help improving the provider!

[sujith1594]

Hi @jaylonmcshan19-x

For Issue 1, we are able to upgrade to the new versions of the chart after either adding the postrender in lifecycle ignore_changes block or setting the default value in the variable like below

postrender   = {
 args        = []
 binary_path = ""
} 

But why it is detecting changes in the first place after upgrading to 3.0.x, Not only for postrender we are seeing changes for few other arguments as well. We see changes for below 4 arguments after upgrading to v3

- postrender                 = {
  - args        = [] -> null
  - binary_path = "" -> null
} -> null

- set_list                   = [] -> null
- set_sensitive              = [] -> null
- set_wo_revision            = 1 -> null

We can overcome them by setting the above values in default values of the variables, but want to be sure if this will cause any issues in the future as there is no rollback option to 2.x.x once the changes are applied with 3.0.x version

Issue 2 is completely resolved, now the resources are being deployed in the namespace mentioned in the helm_resource block

For Issue3 chart gets deployed/upgraded even if we prefix with "v" or not. This is happening only for cert-manager and vault-secrets-operator helm charts. If you can let me know why it is detecting the change only in 3.0.x it would be great.

Thanks,
Sujith

[federico-ledn]

We are also seeing the same changes in our plans, although nothing changed other than migrating to 3.0 ... And additionally our sets all show changes in the order now, when it used to be alphabetically sorted so it didn't matter how we put it in our code, but that changed too?

 - postrender                 = {
          - args        = [] -> null
          - binary_path = "" -> null
        } -> null
...
# Change in order now respecting the code order, but used to be alphabetically sorted in <3.0
~ {
              ~ name  = "region" -> "disableRestrictedSecurityGroupRules"
              ~ value = "us-east-1" -> "true"
                # (1 unchanged attribute hidden)
            },
          ~ {
              ~ name  = "serviceAccount.create" -> "disableIngressClassAnnotation"
              ~ value = "false" -> "true"
                # (1 unchanged attribute hidden)
            },
...

- set_list                   = [] -> null
      - set_sensitive              = [] -> null
      - set_wo_revision            = 1 -> null