terraform-provider-helm
terraform-provider-helm copied to clipboard
Provider does not create diff for local chart changes
Issue was reported here but the title is unclear and that issue was closed. Also a fix is suggested here, but seems to be stuck since the original issue was closed out.
Seeing this issue with helm3.
When keeping charts locally, changes to the template yaml files will not cause a diff when running terraform plan
. I've worked around this by incrementing the local chart version or using taints.
Terraform v0.12.24
Provider Version
helm (hashicorp/helm) 1.2.1
Affected Resource(s)
- helm_release
Expected Behavior
Diff should be created when a template changes
Actual Behavior
No diff was created
Steps to Reproduce
- Create a local chart with a template
- Create a helm release resource that utilizes the chart
- Run
terraform apply
to create the resource - Update the template yaml
- run
terraform plan
orterraform apply
and see no diff is created.
References
- https://github.com/terraform-providers/terraform-provider-helm/issues/346
- https://github.com/terraform-providers/terraform-provider-helm/pull/357
As described on the helm documentation (I read it but I couldn't find it, right now) a the release version should be increased every time a change happened on it, at least if you want to redeploy it. Are you upgrading the version?
Updating the chart version is my "workaround" to get the tf diff, but from your comment that means it's expected behavior. I found it called out as a comment on this page: https://helm.sh/docs/topics/library_charts/.
It's a little at odds with how terraform works in that any change in tf almost always generates a diff, but you've shown this isn't a bug in the provider. Thanks for your quick response!
Oh! Great you found it, I was searching for it several minutes, and I knew it, I read it!
This version number should be incremented each time you make changes to the chart and its templates, including the app version.
So yes, this is the expected behavior this doesn't mean that is odd. What I expect is that if I change a line in the chart should be updated. I agree, actually, I have a workaround in my code base that add as fake hash
value to the release with an md5 of the chart folder.
The idea behind #357, is perfectly valid, the problem is that lacks the acceptance test, usually the hardest part to do in a chart, I will try to allocate some time to fix this.
This version number should be incremented each time you make changes to the chart and its templates, including the app version.
I am not sure, but this advise seems rather to apply in cases where the chart is actually released to some repository, where others would reference it by name and version. In cases where one simply keeps the chart locally and deploys it, I think it produces a strange development experience, especially when compared how other terraform resources are handled and that the resource is already versioned when it is part of a terraform module. At least it took me some time to recognize this behavior and search for this issue here.
I agree that this produces a strange/unpleasant developer experience when using local charts. Perhaps a force_deploy
flag that would force helm upgrade
could work?
A colleague of mine came up with the idea to pass
resource "helm_release" "my_release" {
values = [
...,
yamlencode({
dummy: uuid()
})
]
}
This way the values are changed each time which leads to the helm release being always applied. We use this when we develop a terraform module that includes helm charts and later on increment the version of the module when we are happy with the changes.
Still this is a hack.
Faced similar issues - had to fallback to @JarnoRFB hack
@JarnoRFB's hack triggers an upgrade at every apply, not only when the local chart changes. Here is an upgrade to the hack that does not suffer from that drawback:
- Compute a hash of the chart's contents:
locals {
chart_path = "./my-chart"
# Terraform's helm provider does not detect diffs in a local chart.
# Github issue: https://github.com/hashicorp/terraform-provider-helm/issues/515
# Our workaround: add a dummy value containing a hash of the chart's contents.
chart_hash = md5(join("", [
for f in fileset(local.chart_path, "**") :
filemd5(format("%s/%s", local.chart_path, f))
]))
}
- Add the hash to the release's values:
resource "helm_release" "example" {
name = "my-release"
namespace = "my-namespace"
chart = local.chart_path
values = [
...,
yamlencode({
chart_hash : local.chart_hash,
})
]
}
Marking this issue as stale due to inactivity. If this issue receives no comments in the next 30 days it will automatically be closed. If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. This helps our maintainers find and focus on the active issues. Maintainers may also remove the stale label at their discretion. Thank you!
not stale - the provider should be doing this md5 if at all possible on local charts