-
Notifications
You must be signed in to change notification settings - Fork 24
How to update .terraform.lock.hcl introduced in Terraform v0.14 #32
Description
Terraform v0.14 will introduce a dependency lock file named .terraform.lock.hcl, which splits a concept of version constraint and selection.
https://discuss.hashicorp.com/t/terraform-0-14-the-dependency-lock-file/15696
https://github.com/hashicorp/terraform/blob/v0.14/website/docs/configuration/dependency-lock.html.md
Before Terraform v0.14, we can use only a version constraint in Terraform configurations, so we update the constraint with tfupdate. Actually that is why I wrote the tfupdate.
After Terraform v0.14, we can continue to update the version constraint with tfupdate. There is no syntax change for the version constraint. However we now need to update the lock file too. How should we do it?
First of all, this change only affects provider dependencies at the time of writing, that is to say, it only affects the tfupdate provider command. Module dependencies expect to be implemented for future Terraform versions and I think the Terraform core version selection is unlikely to be implemented.
The easiest way to use Terraform v0.14 with tfupdate is adding .terraform.lock.hcl to .gitignore. It just works as the same as Terraform v0.13, but it means you can't verify hashes for providers recorded in the lock file.
A recommended way is to use the terraform providers lock command to update the lock file. Note that if you run terraform on multiple platforms such as linux, mac and windows, it requires to pre-populate hashes for all platforms you need to avoid a lock file drift.
One more thing you should know is there are two hash algorithms for now, that is, zh and h1.
- The
zhhash is a legacy zip package hash, which is recorded only when you install a provider directly from Terraform Registry. - The
h1hash is a non-zip content-based hash, which is recorded when you install a provider from a mirror or cache.
I assume most of the tfupdate users manage multiple directories, so it's recommend to use the terraform providers mirror command which prepares a local filesystem mirror to avoid duplicate downloads. This means that we should only use the h1 hash. It works fine as long as the lock file is always generated on CI with a consistent way. In this case, you should not run the terraform init -upgrade command manually, because it will add zh hashes to the lock file and result in a lock file change.
I added an example for updating .terraform.lock.hcl on CircleCI.
minamijoyo/tfupdate-circleci-example#113
I understand that it would be great if we could update the lock file without the terraform command. To update the lock file with tfupdate, we probably need to reimplement lots of terraform internals such as select a version, download a provider, verify a checksum, calculate a hash, and update the lock file. I can imagine that it's a non-trivial work and hard to support multiple Terraform versions with a stable way. I can't say anything about the future, but I don't have any plans for now.