The goal of this change is to simplify the process of filing
issues with hashicorp/terraform. In the previous Markdown syntax,
the instructions tended to get washed out in a sea of comment
markers. The new Github Form Issues breaks each section into a form
element, with instructions printed clearly as HTML in the page.
We are further hoping to guide users to the correct repository when
filing provider issues, or the community forums when asking usage
questions.
We've been holding on to this snapshot of the old docs from the v0.11
branch ever since the v0.12 release as a courtesy to folks who are still
using Terraform v0.11, since until now we didn't have any way to serve
older versions' docs on the website alongside the current aside from
snapshotting it forward in this way.
However, our website framework now supports publishing multiple versions
at the same time and so the final resting place for these v0.11 docs will
be in the "v1.1" branch, whose content is serving as the documentation
for the "v1.1 and earlier" version selection on the website. While it does
still feel a little awkward to have v0.11 be a subsection of the v1.1
docs, this is at least more honest in that v0.11 _is_ earlier than v1.1,
whereas it's confusing and weird for it to appear under the "v1.2.x"
option and the other versions that will appear later.
In order to avoid breaking incoming links to the old docs we will deploy
this in conjunction with some additional redirects managed by the top-level
terraform-website repository, which will send all paths with the prefix
/language/configuration-0-11 to the equivalent path under
/language/v1.1.x/configuration-0-11 . That redirect rule must exist
outside of this repository because it's a bridge _between_ versions of
the website in this repository, rather than a link to other content within
the same version.
We can't validate that data from deprecated nested attributes is used in
the configuration, but we can at least catch the simple case where a
deprecated attribute is referenced directly.
All the code infrastructure was there to support formatting multiple
files already.
This makes `terraform fmt` more flexible and also compliant with the
[treefmt formatter
spec](https://numtide.github.io/treefmt/docs/formatters-spec.html)
The StaticValidateTraversal code was not taking into account nested
structural types. Rather than create more special cases for checking
Type vs NestedType, we move the ImpliedType method up to the Attribute
to ensure both are used to generate the final type spec.
If there are outputs in configuration, a destroy plan will always contain a "delete" change for each of these outputs.
This leads to meaningless delete changes being present for outputs which were not present in state and therefore cannot be deleted. Since there is a change in the plan, this plan will then be considered applyable, and the user will be presented with text instructing them to apply a plan in which there are no actual changes.
This commit stops the above from happening in the case of root module outputs.
