providercache: Discard lock entries for unused providers #30192
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously we would only ever add new lock entries or update existing ones. However, it's possible that over time a module may cease using a particular provider, at which point we ought to remove it from the lock file so that operations won't fail when seeing that the provider cache directory is inconsistent with the lock file.
Now the provider installer (
EnsureProviderVersions
) will remove any lock file entries that relate to providers not included in the given requirements, which therefore makes the resulting lock file properly match the set of packages the installer wrote into the cache.This does potentially mean that someone could inadvertently defeat the lock by removing a provider dependency, running
terraform init
, then undoing that removal, and finally running "terraform init" again. However, that seems relatively unlikely compared to the likelihood of removing a provider and keeping it removed, and in the event it did happen the changes to the lock entry for that provider would be visible in the diff of the provider lock file as usual, and so could be noticed in code review just as for any other change to dependencies.This fixes #30122.
I included a note in the updated documentation about the possibility of needing to run
terraform init
to clean up stale entries after upgrading to Terraform v1.1, but that note only really applies in the unusual case of upgrading to Terraform v1.1 in an already-initialized working directory and trying to directly run a command liketerraform apply
without first re-runningterraform init
using the new version. In the more usual case of initializing the directory with Terraform v1.1 before running any other commands, the removal will happen automatically and no extra step will be required.