- Notifications
You must be signed in to change notification settings - Fork905
Description
Background
When we run a Terraform provisioner job, we runterraform init
to download modules before running the plan / apply.
When uploading a template, we encourage users to runterraform 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 runterraform 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 recordedin the .terraform.lock.hcl file. Review those changes and commit them to yourversion 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 directoryTerraform has been successfully initialized!
The fix for this is to re-runterraform init
on a version of Terraform with the same OS/arch.
Proposed Solution
- Record the checksum of
.terraform.lock.hcl
before and after runningterraform 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.