We have a
.terraform.lock.hcl file in the root of the project that contains the versions and hashes of the providers for the OSs we develop on / deploy with. This file is committed to the repo.
Our pipelines caches the following paths:
terraform-plugins: /root/.terraform.d/plugin-cache terraform-local-plugins: .terraform/plugins terraform-modules: .terraform/modules
With this setup, our pipelines do not need to download and install providers that the pipeline has already seen. If the developers update a provider version, then this will be added to the cache. The pipeline automatically expires the caches after 7 days.
Developers who are using Terraform for multiple projects will also benefit locally as they keep their provider versions uptodate.
All is nice and efficient and the world is Terraformed. Nearly.
The problem we have at the moment is the use of GitHub - antonbabenko/pre-commit-terraform: pre-commit git hooks to take care of Terraform configurati (v1.50.0).
Some of the projects have a
modules directory with multiple modules as sub-directories (only 1 level deep so far, but I can imagine that this may or may not always be the case). These modules are not externally stored and pulled in via a git or http URL, but just modules that are really only reusable within the project in which they are placed.
One element of the pre-commit tool is to run
terraform validate in each directory. This has the side effect of producing a
.terraform.d directory and a
.terraform.lock.hcl file in each module.
What we are unsure of is if these new
.terraform.lock.hcl files should be committed in the same way as the one in the root of the project.
In addition to this, we do regularly update the versions of the providers we want to use as we evaluate the changes.
We use the
terraform providers lock command in the root of the project. Should we be running this in each module also as the only changes are in the root directory.
Are we being over critical/restrictive with regard to the
If we were only using semantic versions in our
versions.tf file, then we are leaving ourselves open to abuse from a re-tagged commit/build of the provider, so having the
.terraform.lock.hcl file would seem to a good security measure and matches what we have with other languages (PHP’s
composer and Node).
So, really, just trying to work out what the best / recommended practise here is.
We have about 20 Terraform projects, some with dozens of modules.
We use a
makefile to simplify the most common day-to-day tasks for the developers, and so, if we need to clear out the
.terraform.d directory and the
.terraform.lock.hcl file from the module, we can do that without breaking the developers workflow.