During the language/CLI docs reorg, we noticed several pages that were no longer
viable; some were redundant, some useless, and some just very obsolete.
Since we were trying to avoid breaking links at the time, we opted to remove
them from the navs and leave them as "ghost pages" — still accessible, but not
findable.
This commit finally cleans these ghosts up and updates any remaining links to
relevant modern pages. Bustin' makes me feel good. 👻🚫
When planning a data source change, the object compatibility
verification step should be performed with unmarked values. This value
is transient and preserving marks is not necessary, and the object
change code is not fully marks-aware.
The tainted state was checked against `cty.NilVal`, however it was
always being set to a null value.
The refreshed state value was being shadowed, and not used in the
following plan.
The existing context test files are becoming quite unwieldy.
Start new ones both to make editing easier, and to help discourage the
copy+pasting of older test patterns we no longer need.
This was not done consistently in all cases when the individual
provisioner graph nodes were used. Since we removed the graph nodes, the
only thing left is to close these at the end of the walk.
Provisioners are always run via a single instance, and their
configuration and references are taken care of via their parent
resource, so there is no need to maintain the provisioner graph nodes.
The only action that will still need to be completed is calling the
Close method for external plugins. This was not consistently done with
the current handling of provisioners anyway, and we can now add that to
a single point with the new CloseProvisioners context method.
InitProvisioner only stored the provisioner in the cache and provided a
way to return an error. We can push this back further into the cli init
process, but for now we can move the error into the Provisioner call and
drop InitProvisioner.
This also changes CloseProvisioner to CloseProvisioners, in preparation
for the removal of the graph nodes.
Previously the state migration process was using the fallback strict
error check when migrating to or from a Terraform Cloud workspace. This
resulted in an error when running init if the local and remote Terraform
versions did not exactly match.
This was excessively strict. When migrating from a remote Terraform
Cloud workspace to local state, there is no need for a version check at
all, as we cannot break the Terraform Cloud workspace. When migrating
to Terraform Cloud, we should use the more forgiving check, rather than
the strict equality.
This commit fixes both of these cases accordingly, and allows migrating
state to and from Terraform Cloud remote workspaces without errors.
I frequently see people attempting to ask questions about Terraform's
error and warning messages but either only copying part of the message or
accidentally copying a surrounding paragraph that isn't part of the
message.
While I'm sure some of these are just "careless" mistakes, I've also
noticed that this has sometimes overlapped with someone asking a question
whose answer is written directly in the part of the message they didn't
include when copying, and so I have a theory that our current output
doesn't create a good enough visual hierarchy for sighted users to
understand where the diagnostic messages start and end when we show them
in close proximity to other content, or to other diagnostic messages.
As a result, some folks fail to notice the relevant message that might've
answered their question.
I tried a few different experiments for different approaches here, such
as adding more horizontal rules to the output and coloring the detail
text differently, but the approach that felt like the nicest compromise
to me was what's implemented here, which is to add a vertical line
along the left edge of each diagnostic message, colored to match with the
typical color we use for each diagnostic severity. This means that the
diagnostics end up slightly indented from what's around them, and the
vertical line seems to help subtly signal how we intended the content
to be grouped together.
Rather than using a prior value of null to indicate create, which is
imprecise because null is a valid output value, only plan values that
didn't exist in the prior state as Create changes.
The planning logic here was inspired by resources, but unlike resources
a null value is valid for an output and does not necessarily indicate it
is being removed. If both before and after are null, the change should
be NoOp. When an output is removed from the configuration, we have a
separate node to create a Delete action to remove it from the state.
Nick Fagerlund