-
Notifications
You must be signed in to change notification settings - Fork 9.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Treat .terraform/providers as a cache to avoid re-downloading on subsequent "terraform init" in the same directory #27155
Comments
This behavior seems to be by design. to solve the caching issue you mentioned you need to tell terraform to cache the plugins. Add this line in $HOME/.terraformrc
then it should work as expected. Not sure why this is not the default behavior. |
@adicostil - thanks for this! This helps to "workaround" the problem seen with terraform I tested this with terraform This is the Terraform
|
terraform init
redownloads plugins every time (reopen request)terraform init
redownloads plugins every time (reopen request)
terraform init
redownloads plugins every time (reopen request)terraform init
redownloads plugins every time (reopen request)
Hi all, What's happened here is that previously Terraform was using the contents of the Of course, a side-effect of that new design is that the lock file can only specify a version, and can't also serve as a sort of implied "cache" of the packages. Therefore Terraform always installs what the lock file says because the lock file doesn't contain any packages. It would be possible in principle for Terraform to treat the |
terraform init
redownloads plugins every time (reopen request)
@apparentlymart - Thanks for the explanation. Now I understand how this behaviour relates to the new lock mechanism. For now, I will use the plugins-cache-dir as a workaround to achieve the desired cache behaviour. keep up the good work! |
Only that the offered work around doesn't work too. |
@erezool - The workaround works for me. I am using a client configuration file
|
@joncolby Thanks for replying. It does work now and I didn't change a thing. Pretty strange I must say |
Hi all! It looks like this issue was duplicated with #27534, but we didn't notice at the time. We resolved that in v0.14.6 so that Terraform's installer will now only attempt to fetch and install a provider package if the version indicated in the lock file isn't already present. That is, in effect, what I described in my earlier comment above. Given that, I'm going to close this. If you are still seeing redundant installation on Terraform v0.14.6 or later then please open a new issue to discuss that, since the details of how the installer works are now different than they were for this issue and so we'll need to start over with a new set of debug/trace logs, etc, in order to investigate. Thanks! |
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. |
This new issue re-raises an issue that I believe was incorrectly closed. Issue #27099 was closed with the reason "duplicate issue of #27092", however the issue used as a reason to close #27099 is not the same use case.
Problem: running
terraform init
multiple times should re-use previously downloaded provider versions. It seems like terraform providers are always downloaded, regardless of any additional settings.Due to this issue, the added time to re-download providers with every run causes terraform workflows to take longer
Terraform Version
Expected Behavior
Running
terraform init
2 or more times, with no provider version changesActual Behavior
Terraform Init First Run
Terraform init Second run
Relevant Configuration
Steps to Reproduce
Please list the full steps required to reproduce the issue, for example:
terraform init
(multiple times for the same configuration)References
Are there any other GitHub issues (open or closed) or Pull Requests that should be linked here? For example:
-get-plugins=false
does not fail as expect in 0.13.x and beyond. #27092 (closed, associated with this problem, but not the same use case)The text was updated successfully, but these errors were encountered: