# shouldn't it be true if the error count is zero
error_count (number): A zero or positive whole number giving the count of errors Terraform detected. If valid is 'true' then error_count will always be zero, because it is the presence of errors that indicates that a configuration is invalid.
The -var command line option comes with the disadvantage that a user must
contend both with Terraform's own parser and with the parser in whichever
shell they've decided to use, and different shells on different platforms
have different rules.
Previously we've largely just assumed that folks know the appropriate
syntax for the shell they chose, but it seems that command lines involving
spaces and other special characters arise rarely enough in other commands
that Terraform is often the first time someone needs to learn the
appropriate syntax for their shell.
We can't possibly capture all of the details of all shells in our docs,
because that's far outside of our own scope, but hopefully this new
section will go some way to give some real examples that will help folks
figure out how to write suitable escape sequences, if they choose to
set complex variable values on the command line rather than in .tfvars
as we recommend elsewhere on this page.
* command: new command, terraform add, generates resource templates
terraform add ADDRESS generates a resource configuration template with all required (and optionally optional) attributes set to null. This can optionally also pre-populate nonsesitive attributes with values from an existing resource of the same type in state (sensitive vals will be populated with null and a comment indicating sensitivity)
* website: terraform add documentation
* jsonplan and jsonstate: include sensitive_values in state representations
A sensitive_values field has been added to the resource in state and planned values which is a map of all sensitive attributes with the values set to true.
It wasn't entirely clear to me if the values in state would suffice, or if we also need to consult the schema - I believe that this is sufficient for state files written since v0.15, and if that's incorrect or insufficient, I'll add in the provider schema check as well.
I also updated the documentation, and, since we've considered this before, bumped the FormatVersions for both jsonstate and jsonplan.
Seems like we lost a newline in some of the shuffling it took to get this
into the live website, and so it's formatting oddly in the rendered
website. This restores the intended formatting of this as the start of
a bullet list, rather than as a continuation of the previous paragraph.
* clarify input variables opening sentence
* adjust variables description
* claraify providers text and add learn callout
* add description to providers page
* add desscription and clarify provider configuration
* add deprecation note to versions in proivder configs
* add hands on callout and clarify next steps in intro
* link to language collection from language docs
* give more context about configurtion language up front
* clarify output top page
* reorganize for each intro to present feature before notes
* move description before link out and remove passive voice
* fix typo
* clarify purpose of plan
* move explanation before learn link and fully spell boolean
* add a syntax heading to separate intro from details
* add learn callout to module source docs
* clean up intro to provider requirements and add link
* Apply suggestions from code review
Co-authored-by: Tu Nguyen <im2nguyen@users.noreply.github.com>
* Apply suggestions from code review
Co-authored-by: Tu Nguyen <im2nguyen@users.noreply.github.com>
Co-authored-by: Tu Nguyen <im2nguyen@users.noreply.github.com>
Laura Pacilio