Prevously the cloud backend would only render post-plan run tasks. Now
that pre-plan tasks are in beta, this commit updates the plan phase to
render pre-plan run tasks. This commit also moves some common code to
the common backend as it will be used by other task stages in the
future.
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.
Previously we didn't describe the interaction between default values and
callers explicitly passing "null".
We treat an explicit null as the same as omitting the attribute when
applying defaults, because that then allows callers to use the typical
pattern for conditional assignment, using explicit null as a fallback
to the module's defined default without having to duplicate that default:
example = var.foo ? "hello" : null
Previously, when applying defaults to an input variable's given value
before type conversion, we would permit `null` attribute values to
override a specified default. This behaviour is inconsistent with the
intent of the type system underlying Terraform, and represented a
divergence from the treatment of `null` as equivalent to unset which
exists in resources. The same behaviour exists in top-level variable
definitions with `nullable = false`, and we consider this to be the
preferred behaviour here too.
This commit slightly changes default value application such that an
explicit `null` attribute value is treated as equivalent to the
attribute being missing. Default values for attributes will now replace
explicit nulls.
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.
