Terraform validation should support configuration

[mauve]

All of these should be configurable:

Usage: terraform validate [options] [dir]

  Validate the terraform files in a directory. Validation includes a
  basic check of syntax as well as checking that all variables declared
  in the configuration are specified in one of the possible ways:

      -var foo=...
      -var-file=foo.vars
      TF_VAR_foo environment variable
      terraform.tfvars
      default value

  If dir is not specified, then the current directory will be used.

Options:

  -check-variables=true If set to true (default), the command will check
                        whether all required variables have been specified.

  -no-color             If specified, output won't contain any color.

  -var 'foo=bar'        Set a variable in the Terraform configuration. This
                        flag can be set multiple times.

  -var-file=foo         Set variables in the Terraform configuration from
                        a file. If "terraform.tfvars" is present, it will be
                        automatically loaded if this flag is not specified.

[ranga543]

@mauve I made some changes on forked repo of mine. You can see and tell me if I'm approaching in right way or not for this enhancement

[mauve]

thanks I made some comments

[apparentlymart]

Hi! I'm a member of the Terraform Core development team at HashiCorp.

In hashicorp/terraform#15895 we proposed the idea that terraform validate would have its mission refined to just static validation of the configuration alone, with the primary purpose of being an inexpensive way to detect errors in a text editor, and suitable to run on every save. The validate command would test whether a particular module is valid for any variable values, rather than for a specific set of variable values. To be specific, it'd run the language's semantic checker and report any type inconsistencies or use of unknown names.

This would then distinguish it from terraform plan as the way to validate a particular run of Terraform (including any variables) which would generally be more expensive -- it may access the backend to find stored variable values, etc -- and should be run only on explicit user request.

We are planning to move forward with this change in the next major version of Terraform since the other changes planned for this release meant we needed to significantly rework the implementation of terraform validate anyway.

So with all of this said, the new interface to this command will be considerably simpler (some details may shift before final release, since this is still under development):

Usage: terraform validate [options] [dir]

  Validate the configuration files in a directory, referring only to the
  configuration and not accessing any remote services such as remote state,
  provider APIs, etc.

  Validate runs checks that verify whether a configuration is
  internally-consistent, regardless of any provided variables or existing
  state. It is thus primarily useful for general verification of reusable
  modules, including correctness of attribute names and value types.

  It is safe to run this command automatically, for example as a post-save
  check in a text editor or as a test step for a re-usable module in a CI
  system.

  If dir is not specified, then the current directory will be used.

  Validation requires an initialized working directory with any referenced
  plugins and modules installed. To initialize a working directory for
  validation without accessing any configured remote backend, use:
      terraform init -backend=false

  To verify configuration in the context of a particular run (a particular
  target workspace, operation variables, etc), use the following command
  instead:
      terraform plan -validate-only

Options:

  -json        Produce output in a machine-readable JSON format, suitable for
               use in e.g. text editor integrations.
  -no-color    If specified, output won't contain any color.

Note also the -json flag, which is expressly intended for easier processing by text editor extensions like this one, avoiding the need to parse human-oriented output (which will also be changing in 0.12).

[heldersepu]

@apparentlymart That sounds awesome! looking forward to that feature (hopefully this summer)

[apparentlymart]

Hi again!

I just wanted to update that the changes I mentioned previously are now included in v0.12.0-alpha2, in case that's useful for some early testing. I use this VSCode extension myself anyway so I've been exercising it with the latest changes as I work, but hopefully access to that prerelease version can avoid any surprises in final release.

(As discussed in hashicorp/terraform#19259, the plan -validate-only thing mentioned in the usage output isn't actually there yet, and we're not sure yet whether it'll land for v0.12.0 or in a later release, but I think that's not directly relevant to the needs of this VSCode extension.)

[paultyng]

We just released v2.0.0-rc.1 of the extension. The main features include:

• Added syntax support for 0.12
• Added terraform-ls usage by default (currently on 0.3.0, which offers basic provider code completion)

You can find additional information and specifics in the release notes and CHANGELOG.

With this release we expect that many of the prior issues and PRs are no longer relevant or have been addressed, and are therefore being closed. If you feel the action taken on an issue or PR is in error, please comment as such and we can figure out the appropriate way to address it.

We plan to add the final 2.0.0 release to the marketplace soon, but are actively seeking your feedback now on the release candidates. You can download the .vsix from the releases page and manually install it in VS Code to try it out.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the context necessary to investigate further.