github.com/kanishk98/terraform@v1.3.0-dev.0.20220917174235-661ca8088a6a/website/docs/cli/commands/validate.mdx (about)

     1  ---
     2  page_title: 'Command: validate'
     3  description: >-
     4    The `terraform validate` command is used to validate the syntax of the
     5    terraform files.
     6  ---
     7  
     8  # Command: validate
     9  
    10  The `terraform validate` command validates the configuration files in a
    11  directory, referring only to the configuration and not accessing any remote
    12  services such as remote state, provider APIs, etc.
    13  
    14  Validate runs checks that verify whether a configuration is syntactically
    15  valid and internally consistent, regardless of any provided variables or
    16  existing state. It is thus primarily useful for general verification of
    17  reusable modules, including correctness of attribute names and value types.
    18  
    19  It is safe to run this command automatically, for example as a post-save
    20  check in a text editor or as a test step for a re-usable module in a CI
    21  system.
    22  
    23  Validation requires an initialized working directory with any referenced plugins and modules installed. To initialize a working directory for validation without accessing any configured backend, use:
    24  
    25  ```
    26  $ terraform init -backend=false
    27  ```
    28  
    29  To verify configuration in the context of a particular run (a particular
    30  target workspace, input variable values, etc), use the `terraform plan`
    31  command instead, which includes an implied validation check.
    32  
    33  ## Usage
    34  
    35  Usage: `terraform validate [options]`
    36  
    37  This command accepts the following options:
    38  
    39  * `-json` - Produce output in a machine-readable JSON format, suitable for
    40    use in text editor integrations and other automated systems. Always disables
    41    color.
    42  
    43  * `-no-color` - If specified, output won't contain any color.
    44  
    45  ## JSON Output Format
    46  
    47  When you use the `-json` option, Terraform will produce validation results
    48  in JSON format to allow using the validation result for tool integrations, such
    49  as highlighting errors in a text editor.
    50  
    51  As with all JSON output options, it's possible that Terraform will encounter
    52  an error prior to beginning the validation task that will thus not be subject
    53  to the JSON output setting. For that reason, external software consuming
    54  Terraform's output should be prepared to find data on stdout that _isn't_ valid
    55  JSON, which it should then treat as a generic error case.
    56  
    57  The output includes a `format_version` key, which as of Terraform 1.1.0 has
    58  value `"1.0"`. The semantics of this version are:
    59  
    60  * We will increment the minor version, e.g. `"1.1"`, for backward-compatible
    61    changes or additions. Ignore any object properties with unrecognized names to
    62    remain forward-compatible with future minor versions.
    63  * We will increment the major version, e.g. `"2.0"`, for changes that are not
    64    backward-compatible. Reject any input which reports an unsupported major
    65    version.
    66  
    67  We will introduce new major versions only within the bounds of
    68  [the Terraform 1.0 Compatibility Promises](/language/v1-compatibility-promises).
    69  
    70  In the normal case, Terraform will print a JSON object to the standard output
    71  stream. The top-level JSON object will have the following properties:
    72  
    73  - `valid` (boolean): Summarizes the overall validation result, by indicating
    74    `true` if Terraform considers the current configuration to be valid or
    75    `false` if it detected any errors.
    76  
    77  - `error_count` (number): A zero or positive whole number giving the count
    78    of errors Terraform detected. If `valid` is `true` then `error_count` will
    79    always be zero, because it is the presence of errors that indicates that
    80    a configuration is invalid.
    81  
    82  - `warning_count` (number): A zero or positive whole number giving the count
    83    of warnings Terraform detected. Warnings do not cause Terraform to consider
    84    a configuration to be invalid, but they do indicate potential caveats that
    85    a user should consider and possibly resolve.
    86  
    87  - `diagnostics` (array of objects): A JSON array of nested objects that each
    88    describe an error or warning from Terraform.
    89  
    90  The nested objects in `diagnostics` have the following properties:
    91  
    92  - `severity` (string): A string keyword, currently either `"error"` or
    93    `"warning"`, indicating the diagnostic severity.
    94  
    95    The presence of errors causes Terraform to consider a configuration to be
    96    invalid, while warnings are just advice or caveats to the user which do not
    97    block working with the configuration. Later versions of Terraform may
    98    introduce new severity keywords, so consumers should be prepared to accept
    99    and ignore severity values they don't understand.
   100  
   101  - `summary` (string): A short description of the nature of the problem that
   102    the diagnostic is reporting.
   103  
   104    In Terraform's usual human-oriented diagnostic messages, the summary serves
   105    as a sort of "heading" for the diagnostic, printed after the "Error:" or
   106    "Warning:" indicator.
   107  
   108    Summaries are typically short, single sentences, but can sometimes be longer
   109    as a result of returning errors from subsystems that are not designed to
   110    return full diagnostics, where the entire error message therefore becomes the
   111    summary. In those cases, the summary might include newline characters which
   112    a renderer should honor when presenting the message visually to a user.
   113  
   114  - `detail` (string): An optional additional message giving more detail about
   115    the problem.
   116  
   117    In Terraform's usual human-oriented diagnostic messages, the detail provides
   118    the paragraphs of text that appear after the heading and the source location
   119    reference.
   120  
   121    Detail messages are often multiple paragraphs and possibly interspersed with
   122    non-paragraph lines, so tools which aim to present detail messages to the
   123    user should distinguish between lines without leading spaces, treating them
   124    as paragraphs, and lines with leading spaces, treating them as preformatted
   125    text. Renderers should then soft-wrap the paragraphs to fit the width of the
   126    rendering container, but leave the preformatted lines unwrapped.
   127  
   128    Some Terraform detail messages currently contain an approximation of bullet
   129    lists using ASCII characters to mark the bullets. This is not currently a
   130    contractural formatting convention and so renderers should avoid depending on
   131    it and should instead treat those lines as either paragraphs or preformatted
   132    text per the rules above. A future version of this format may define some
   133    additional rules for processing other text conventions, but will do so within
   134    the bounds of the rules above to achieve backward-compatibility.
   135  
   136  - `range` (object): An optional object referencing a portion of the configuration
   137    source code that the diagnostic message relates to. For errors, this will
   138    typically indicate the bounds of the specific block header, attribute, or
   139    expression which was detected as invalid.
   140  
   141    A source range is an object with a property `filename` which gives the
   142    filename as a relative path from the current working directory, and then
   143    two properties `start` and `end` which are both themselves objects
   144    describing source positions, as described below.
   145  
   146    Not all diagnostic messages are connected with specific portions of the
   147    configuration, so `range` will be omitted or `null` for diagnostic messages
   148    where it isn't relevant.
   149  
   150  - `snippet` (object): An optional object including an excerpt of the
   151    configuration source code that the diagnostic message relates to.
   152  
   153    The snippet information includes:
   154  
   155    - `context` (string): An optional summary of the root context of the
   156      diagnostic. For example, this might be the resource block containing the
   157      expression which triggered the diagnostic. For some diagnostics this
   158      information is not available, and then this property will be `null`.
   159  
   160    - `code` (string): A snippet of Terraform configuration including the
   161      source of the diagnostic. This can be multiple lines and may include
   162      additional configuration source code around the expression which
   163      triggered the diagnostic.
   164  
   165    - `start_line` (number): A one-based line count representing the position
   166      in the source file at which the `code` excerpt begins. This is not
   167      necessarily the same value as `range.start.line`, as it is possible for
   168      `code` to include one or more lines of context before the source of the
   169      diagnostic.
   170  
   171    - `highlight_start_offset` (number): A zero-based character offset into the
   172      `code` string, pointing at the start of the expression which triggered
   173      the diagnostic.
   174  
   175    - `highlight_end_offset` (number): A zero-based character offset into the
   176      `code` string, pointing at the end of the expression which triggered the
   177      diagnostic.
   178  
   179    - `values` (array of objects): Contains zero or more expression values
   180      which may be useful in understanding the source of a diagnostic in a
   181      complex expression. These expression value objects are described below.
   182  
   183  ### Source Position
   184  
   185  A source position object, as used in the `range` property of a diagnostic
   186  object, has the following properties:
   187  
   188  - `byte` (number): A zero-based byte offset into the indicated file.
   189  
   190  - `line` (number): A one-based line count for the line containing the relevant
   191    position in the indicated file.
   192  
   193  - `column` (number): A one-based count of _Unicode characters_ from the start
   194    of the line indicated in `line`.
   195  
   196  A `start` position is inclusive while an `end` position is exclusive. The
   197  exact positions used for particular error messages are intended for human
   198  interpretation only and subject to change in future versions of Terraform due
   199  either to improvements to the error reporting or changes in implementation
   200  details of the language parser/evaluator.
   201  
   202  ### Expression Value
   203  
   204  An expression value object gives additional information about a value which is
   205  part of the expression which triggered the diagnostic. This is especially
   206  useful when using `for_each` or similar constructs, in order to identify
   207  exactly which values are responsible for an error. The object has two properties:
   208  
   209  - `traversal` (string): An HCL-like traversal string, such as
   210    `var.instance_count`. Complex index key values may be elided, so this will
   211    not always be valid, parseable HCL. The contents of this string are intended
   212    to be human-readable and are subject to change in future versions of
   213    Terraform.
   214  
   215  - `statement` (string): A short English-language fragment describing the value
   216    of the expression when the diagnostic was triggered. The contents of this
   217    string are intended to be human-readable and are subject to change in future
   218    versions of Terraform.