Here we propagate in the initialized terminal.Streams from package main,
and then onwards to backends running in CLI mode.
This also replaces our use of helper/wrappedstreams to determine whether
stdin is a terminal or a pipe. helper/wrappedstreams returns incorrect
file descriptors on Windows, causing StdinPiped to always return false on
that platform and thus causing one of the odd behaviors discussed in
Finally, this includes some wrappers around the ability to look up the
number of columns in the terminal in preparation for use elsewhere. These
wrappers deal with the fact that our unit tests typically won't populate
meta.Streams.
We need to call into terminal.Init in early startup to make sure that we
either have a suitable Terminal or that we disable attempts to use virtual
terminal escape sequences.
This commit gets the terminal initialized but doesn't do much with it
after that. Subsequent commits will make more use of this.
This is a helper package that creates a very thin abstraction over
terminal setup, with the main goal being to deal with all of the extra
setup we need to do in order to get a UTF-8-supporting virtual terminal
on a Windows system.
This adds a CI job for running the new PR link checker for documentation.
[terraform-website PR 1574](https://github.com/hashicorp/terraform-website/pull/1574)
added a new link checking CI job specifically for warning about broken links in
pull requests. This link checker is optimized for:
- Running (relatively) quickly.
- Only reporting on files that were changed in the current PR, to avoid spamming
you with problems you had nothing to do with.
- Being transparent and simple to maintain. (Note that this is in conflict with
minimizing false positives/negatives! We try to give very few of both, but
completely eliminating them would result in an unaffordable maintenance
burden. We expect that some PRs will be merged with this job red.)
The tool is somewhat specific to our Middleman site builder, and we expect it
will be replaced or obviated in the transition to the Next.js platform... but in
the meantime, it should help make documentation slightly easier to maintain.
Remove any calls to testDiffFn and testApplyFn which don't effect the
test result. This way we have more tests using predictable provider
behavior, which is more likely to uncover legitimate regressions as the
particular behavior of the legacy mock provider logic does not need to
be taken into account.
Now that we don't need to track separate error values for the apply
logic, it's easier to reorganize the diagnostic handling to use a single
set of diagnostics.
Trying to track these error values as they wint into and out of the
instance apply methods was quite difficult. They were mis-assigned, and
in many cases lost diagnostic information.
Various pieces of the state and/or warnings were dropped when the
provider returns an error. Do a little cleanup of `.apply` to make the
logic easier to follow.
After verifying the remote backend workspace version is compatible with
the local Terraform version, we need to record that this check was
successful. Otherwise the fallback error handling path will run a strict
version check, even if the versions are compatible, which will cause an
unexpected failure.
Add reasonable default behavior to the mock provider, so that may do not
need to depend on the idiosyncrasies of the old (though updated) test
testDiffFn and to a lesser extend the testApplyFn. This behavior is
based directly upon the documented resource lifecycle, rather
than be an ad-hoc collection of behaviors from old tests.
As a proof of concept, remove all uses of testDiffFn from the plan
context tests that don't cause the tests to fail.
The revision field is only populated on dev builds so this means
most releases of Terraform have an empty "terraform_revision" field
in the JSON output. Since we recommend developers use go tooling
to `go build` this tool when developing, the revision is not useful
data and so it is removed.
There are a few places where we want to perform some transformation on a
cty.Value, but require information from the schema. Rather than create
bespoke functions to walk the cty.Value and schema in concert, we can
provide Attribute information from a cty.Path allowing the use of
Value.Transform in these cases.
This allows up to detect an unset value from the zero value so that
defaults can be implemented, while still allowing tests to return
specific values of their choosing.
When running state mv with a resource source, but the destination
fails, provide a hint that the source is a resource (not an instance)
in case the user means to address it this way
Using the addrTo after it has failed its check means <invalid>/no
address will be printed. Change this throughout, but particularly
add a test for the origin issue for this.
Martin Atkins