Helm charts (almost) always re-deploy even when nothing has changed

[worldofgeese]

Bug

I make use of a hefty Helm chart (CockroachDB's) inside a helm Garden module. Even when no values have been changed, on garden deploy it's very likely Garden will version and release a new chart to the cluster, which can take up to minutes. One of our community members also experiences this bug.

Current Behavior

Here are two separate releases deployed to my cluster of the same chart. You can see one update can take up to 164 seconds so it's quite costly.

Nothing has changed in the chart or the values provided to the chart.

Expected behavior

Charts should only cut a new release version when an input value has changed.

Reproducible example

Use my full-fat example with your own authenticated deployment registry defined.

Workaround

None.

Your environment

• OS: Windows 11 running WSL
• How I'm running Kubernetes: GKE Autopilot

garden version
0.12.48

[ashwiren]

My experience has been that this only seems to happen if there are garden variables as values in the helm chart values.

If you have a static values in the helm chart then there's no redeployment.

examples:
No redeployment

kind: Module
description: In-cluster Redis for glx-connect
type: helm
name: redis
chartPath: ./redis
values:
  architecture: 'standalone'
  auth:
    enabled: false
  master:
    resources:
      limits:
        cpu: 500m
        memory: 256Mi
      requests:
        cpu: 50m
        memory: 128Mi

Redeploys.

kind: Module
description: In-cluster PostgreSQL for Keycloak
disabled: ${var.keycloak.database.rds} # if rds is enabled, see infrastructure-aws
type: helm
name: keycloak-pg
chartPath: ./postgresql
dependencies: 
  - infrastructure-aws
values:
  architecture: 'standalone'
  auth:
    database: ${var.keycloak.database.name}
    username: ${var.keycloak.database.username}
    password: "${runtime.services.infrastructure-aws.outputs.keycloak_db_password}"

[vvagaytsev]

Closing as done via #5138.

[vvagaytsev]

It looks like this is happening again, see https://discord.com/channels/817392104711651328/1199912856355881121/1199912856355881121

[stefreak]

This issue might finally be addressed by #6745 – I stumbled across this issue when refactoring the module resolver, when I noticed that we factor the value of overrides into the configuration itself, which affects version calculation.

Thinking about this, I realised that we should exclude variables and varfiles from version calculation, since only their effect on the spec and other relevant fields should be taken into account for version calculation.

WDYT, am I missing something @thsig @vvagaytsev?

See also 7aa19b6