Background

When we run a Terraform provisioner job, we run terraform init to download modules before running the plan / apply.

When uploading a template, we encourage users to run terraform init locally to ensure that a .terraform.lock.hcl file is created. This allows Coder to improve provisioning speeds by re-using previously downloaded provider versions.

Problem

If you run terraform init to create a .terraform.lock.hcl, Terraform will initialise the lock file with provider hashes based on your OS/arch. If you run this on a different architecture to your target Coder instance, you may end up with missing hashes in your lock file.

Your only warning of this will be the following message in the provisioner job log:

- Reusing previous version of hashicorp/aws from the dependency lock file
- Installing hashicorp/aws v5.99.1...
- Installed hashicorp/aws v5.99.1 (signed by HashiCorp)
Terraform has made some changes to the provider dependency selections recorded
in the .terraform.lock.hcl file. Review those changes and commit them to your
version control system if they represent changes you intended to make.
Terraform has been successfully initialized!

What you really want to see is:

- Reusing previous version of hashicorp/aws from the dependency lock file
- Using hashicorp/aws v5.99.1 from the shared cache directory
Terraform has been successfully initialized!

The fix for this is to re-run terraform init on a version of Terraform with the same OS/arch.

Proposed Solution

• Record the checksum of .terraform.lock.hcl before and after running terraform init.
• If the checksum changes, warn the user that they may be downloading Terraform providers unnecessarily and direct them to re-generate the lockfile manually on the same OS/arch as Coder.
• We can also attempt to highlight the message regarding changes to the lockfile in the UI.
• Stretch goal: expose a provisioner method to run terraform init and update the lockfile if there are any changes.