Every job in a busy CI system downloads the same providers again during terraform init, which slows runs and hits rate limits. The repository already commits .terraform.lock.hcl. Which change addresses this in a supported way?
Select an answer to reveal the explanation.
Short Explanation
Why buy the same toolbox for every job? Set up a shared shelf with a plugin cache that the CI system keeps between runs, and init grabs providers from there. The committed lock file makes sure that whatever's on the shelf is exactly the version you agreed on.
Full Explanation
Terraform's provider plugin cache stores downloaded provider packages in a shared directory so later init runs can reuse them instead of downloading again. It can be configured with plugin_cache_dir in the CLI configuration or, more conveniently in CI, with the TF_PLUGIN_CACHE_DIR environment variable pointing at a directory the CI system restores between jobs. The committed lock file keeps selections and checksums consistent, so cached packages are reused only when they match the recorded versions and hashes. Committing the .terraform directory puts platform-specific binaries and local working state into version control, which HashiCorp does not support and which breaks across operating systems and architectures. The -get=false option skips child module installation and has nothing to do with provider downloads. -upgrade does the opposite of what is wanted: it ignores the lock file's selections and looks for newer versions on every run, adding registry traffic and changing versions unexpectedly. Exam caveat: if the lock file lacks checksums for the CI platform, Terraform may not use cached packages, so lock files should include hashes for every platform that runs Terraform. Operational check: compare init logs between two consecutive jobs and confirm the second reports using providers from the cache.