You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When directly pinning all versions already (as recommended by Hashicorp), and / or when using tools like Renovate to manage dependencies, the lockfile doesn't seem to add much, other than checking the hashes. While a user can ignore Hashicorp's suggestion to commit the lockfile, as we have, terraform will still create the lockfile locally, and complain if you try to run terraform init without --upgrade if the version changes. I get the reason behind creating the lockfiles, but IMO, it might have been nice to implement it a bit more slowly and / or with a bit more optionality.
While I suspect they (Renovate) will try, it's difficult for third party dependency managers to correctly and accurately keep lockfiles up to date for all tf lockfile versions that might exist in the future.
Having to explicitly run terraform init -upgrade to a version that's already explicitly requested (with ==) seems a bit excessive.
Attempted Solutions
using .gitignore to ignore lockfiles works to a point, but is still a hassle for local apply when versions get updated.
Proposal
Suggestions (this could be an either / or thing; happy to make a second feature request if it would help)
a) allow terraform init to automagically imply -upgrade when a version is explicitly requested
b) allow an env var or flag to ignore the lockfile completely and restore the old behavior of terraform init.
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.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.
Current Terraform Version
Use-cases
When directly pinning all versions already (as recommended by Hashicorp), and / or when using tools like Renovate to manage dependencies, the lockfile doesn't seem to add much, other than checking the hashes. While a user can ignore Hashicorp's suggestion to commit the lockfile, as we have, terraform will still create the lockfile locally, and complain if you try to run
terraform init
without--upgrade
if the version changes. I get the reason behind creating the lockfiles, but IMO, it might have been nice to implement it a bit more slowly and / or with a bit more optionality.While I suspect they (Renovate) will try, it's difficult for third party dependency managers to correctly and accurately keep lockfiles up to date for all tf lockfile versions that might exist in the future.
Having to explicitly run
terraform init -upgrade
to a version that's already explicitly requested (with==
) seems a bit excessive.Attempted Solutions
using
.gitignore
to ignore lockfiles works to a point, but is still a hassle for local apply when versions get updated.Proposal
Suggestions (this could be an either / or thing; happy to make a second feature request if it would help)
a) allow
terraform init
to automagically imply-upgrade
when a version is explicitly requestedb) allow an env var or flag to ignore the lockfile completely and restore the old behavior of
terraform init
.References
This comes out of some discussion in #27630
Renovate provider issue: renovatebot/renovate#7895
The text was updated successfully, but these errors were encountered: