.terraform.lock.hcl .gitignore

Should .terraform.lock.hcl be included in the .gitignore file? - No!

Technically, it is not mandatory to commit or even have .terraform.lock.hcl in your Terraform repo

But, it is a best practise to have .terraform.lock.hcl in the repo a for following reasons :

• keeping track of versions & constrains and their hashes ( .terraform.lock.hcl tracks the hashes)

   version     = "5.21.0"
   constraints = ">= 3.72.0, >= 4.47.0, >= 4.57.0, >= 4.66.0, >= 5.0.0"
   hashes = [
     "h1:ImMwRL69SVDMlN9+cIkvR5SQr/TW0/unveRZ6/5xeEI="

• terraform provider version block make sure the tags are consistent, but .terraform.lock.hcl guarantees the entire provider source code is the same

• distribute a lock file to all team members, including CI tools and align the versions of providers

How .terraform.lock.hcl is generated?

Terraform init command creates and populates the lock file

terraform init

Terraform init, checks either provider versions or downloads the laters versions of the providers if lock file is not specified

Lock file or Version or Latest

Is mentioning providers mandatory ?

Unlike many other objects in the Terraform language, a provider block may be omitted if its contents would otherwise be empty.

Terraform assumes an empty default configuration for any provider that is not explicitly configured. https://developer.hashicorp.com/terraform/language/providers/configuration

Some of the providers, have mandatory inputs and you wouldn't able to use the resources. Though, in general Terraform can find and substitude the empty configuration

Though, in most of the cases, it is really helpful to have it for the reasons to lock file usage. It is additional documentation, versioning pinning, better security and audibility

How to update provider versions to the latest version?

terraform init -upgrade

How to support different platforms inside the Terraform lock file?

In real world, not everything is so simple ;)

If you have a big team, and device selection for day to day activities is not standardised , you would have people working on MacOs, Windows, Ubuntu collaborating on same code base.

For this reason, there is a ability to prepopulate the Terraform lock file with supported platforms. This will help to avoid terraform init -upgrade messages, when you use a platform other than your colleague or your CI environment

Specify which platform the provider will include in the lock files

terraform providers lock \
    -platform=windows_amd64 \
    -platform=darwin_amd64 \
    -platform=linux_amd64 \
    -platform=darwin_arm64 \
    -platform=linux_arm64

You can see in the output, that it fetch binaries for all specified platforms and recorded their hashes ...

- Obtained hashicorp/kubernetes checksums for windows_amd64; Additional checksums for this platform are now tracked in the lock file
- Obtained hashicorp/kubernetes checksums for darwin_amd64; All checksums for this platform were already tracked in the lock file
- Obtained hashicorp/kubernetes checksums for linux_amd64; Additional checksums for this platform are now tracked in the lock file
- Obtained hashicorp/kubernetes checksums for darwin_arm64; All checksums for this platform were already tracked in the lock file
- Obtained hashicorp/kubernetes checksums for linux_arm64; Additional checksums for this platform are now tracked in the lock file

Success! Terraform has updated the lock file.

Review the changes in .terraform.lock.hcl and then commit to your
version control system to retain the new checksums.

Documentation from Hashicorp on this topic :

https://developer.hashicorp.com/terraform/language/files/dependency-lock