5 Commits (408f323efa667cd0e105644aa23dcf13efc8a445)

Author	SHA1	Message	Date
Ashlee Boyer	32f7b8ebd0	Migrating links to new format	3 years ago
Bryce Kalow	b54017ef83	website: content updates for developer (#31779) ... Co-authored-by: Matthew Garrell <69917312+mgarrell777@users.noreply.github.com> Co-authored-by: Laura Pacilio <83350965+laurapacilio@users.noreply.github.com> Co-authored-by: Kevin Wang <kwangsan@gmail.com> Co-authored-by: Judith Malnick <judith@hashicorp.com> Co-authored-by: Martin Atkins <mart@degeneration.co.uk> Co-authored-by: HashiBot <62622282+hashibot-web@users.noreply.github.com>	4 years ago
Dan Slimmon	1f6d986595	Include something about how state is checked	4 years ago
Martin Atkins	23395a1022	providercache: Discard lock entries for unused providers ... 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.	4 years ago
Dylan Staley	21cbb5b392	migrate docs to mdx	4 years ago