ashwiren
commented
1 year ago 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: 128MiRedeploys.
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
Bug
I make use of a hefty Helm chart (CockroachDB's) inside a
helmGarden module. Even when no values have been changed, ongarden deployit'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
garden version0.12.48