Show all warnings?

When upgrading to the newest provider or Terraform version, I often need to correct my configs to use the new syntax and change deprecated features. Examples:

  1. Interpolation-only expressions are deprecated in 0.12
  2. The aws_lb_listener_rule in the AWS provider was updated to allow for a different (and better! thank you!) way of specifying conditions.

When I change my Terraform projects to use a new version of the provider or Terraform itself, it would be really helpful to see all warnings, even if there are dozens of them, so that I can correct them quickly. Right now, I have to run terraform plan, read 1 warning along with “(and 9 more similar warnings elsewhere)”, fix it, then run terraform plan again, read the warning with “(and 8 more similar warnings elsewhere)”, repeat until all warnings are resolved. Is there a better way?

Is there a way to have Terraform output all warnings rather than fix “(and 9 more similar warnings elsewhere)” until there are no warnings left? Like -verbose-warnings or something similar?


I haven’t used this - and so don’t know if this could be the solution for your question - but maybe this could help:

Hi @johnstanfield,

There isn’t an explicit way to turn off the “similar warnings elsewhere” truncation, but as a workaround I believe you can force Terraform to show all of the warnings by introducing at least one validation error too. Terraform should show the warnings in full if they are accompanied by at least one error.

It will need to be an error that doesn’t prevent Terraform from processing the parts of the file that the warnings apply to, of course… one idea would be to add an invalid extra argument to one of your resource blocks so that it will fail validation, which shouldn’t block any of the warnings because resource validation happens after initial configuration parsing.

For the “interpolation-only expressions” warning, if you are comfortable working with a Go codebase yourself you might be interested in my side-project tool terraform-clean-syntax, which can take care of most examples of that warning automatically. It has some quirks/bugs because I threw it together quickly, but it should either produce a valid result or change nothing at all. You can use git diff to review what it did and make sure it all looks reasonable.

In case you still need this, the validate command has a JSON output option. This can be piped to jq to get the complete list of validation warnings.

A simple case might be:

terraform validate -json | jq ‘.diagnotics.range | “(.filename):(.start.line)”’

That will show you the filename and line number of all the locations where terraform things the code isn’t valid.

1 Like

Thanks for the terraform validate -json idea, that works perfectly for me! Here’s what I settled on:

terraform validate -json | jq '.diagnostics[] | {detail: .detail, filename: .range.filename, start_line: .range.start.line}'

Since this topic is bumped to the top again, I suppose I can also mention that much of the functionality of my terraform-clean-syntax tool is now built in to terraform fmt in recent Terraform versions, so if you still have some legacy-style syntax warnings to work through then one way to go would be to use Terraform v0.15 just to run terraform fmt (assuming you’re still upgrading an earlier version and aren’t ready for v0.15 yet otherwise) and then continue working with whatever other v0.12-or-later version you were already using.

The terraform fmt in v0.15 won’t produce any syntax that v0.13 and v0.14 can’t also parse.

Thanks for that. In my case, I wasn’t getting warnings that terraform fmt would resolve. It’s the new warnings around "does not declare a provider named aws" and the suggestion to, "add an entry for aws in the required_providers block within the module." This used to be purely optional, but apparently now it’s a warning.

There’s also the similar-ish warning around using an aliased provider block, "Remove the aws.<ALIAS> provider block from module.<MODULE>. Add aws.<ALIAS> to the list of configuration_aliases for aws in required_providers to define the provider configuration name."

I just wanted to see all the warnings so I could better plan out the updates I need to make.

1 Like

This should be pinned somewhere; but really TF should have a way to unsuppress warnings. And a way to suppress them.

Also a shellcheck-style reference to a document explaining what the warning is saying and how to address it. That would be tremendously helpful.


I also support that it is good to be able to see them. E.g. if you have lots of deprecated parameters, it’s a pain to go through them one by one

If you want to display this a little nicer than raw JSON …

terraform validate -json | jq -r '[ del( .diagnostics[] | select( .detail | startswith( "Experimental features" ) ) ) | .diagnostics[] | { Detail:.detail, Address:.address, Filename:.range.filename, Line:.range.start.line } ] | ( .[0] | keys_unsorted | ( . , map( length*"-" ) ) ), .[] | map(.) | @tsv' | column -ts $'\t'

which will produce something like:

Detail                                                          Address                                     Filename                  Line
------                                                          -------                                     --------                  ----
Use the aws_s3_bucket_acl resource instead                      module.efs_backup.aws_s3_bucket.efs_backup  modules/efs_backup/  4
Use the aws_s3_bucket_lifecycle_configuration resource instead  module.efs_backup.aws_s3_bucket.efs_backup  modules/efs_backup/  1
Use the aws_s3_bucket_acl resource instead                      aws_s3_bucket.config_recorder_bucket             191

[EDIT: The above will require jq v1.6]


Supposedly, the work of adding supression is greater than just listing all warnings… so the code is there. It’d be wonderful if there was a command line option to disable this.

Hi @gtirloni,

It is true that there is already code that could in principle show all of the warnings, but there isn’t any code to handle it being a configurable option and it is that code that we don’t wish to add and maintain in all future versions of Terraform, in addition to the existing option to choose between the normal console output vs. the machine-readable JSON output which already allows you to filter or not filter in whatever way you need.

Can you remove the that code entirely then? Less stuff to maintain too. Win-win.

Hi @apparentlymart ,

Surely a simple boolean option is hardly a maintenance burden of any real size?

It’s not like Terraform doesn’t have any other options at all, and you’re being asked to add the very first one.

I too would very much like to see full warning info in my runs.

Indeed, Terraform already has enough options that they create maintenance burden. Hence, we avoid adding new ones unless they allow meeting a new use-case that cannot be met any other way.

There is already a way to view all of the diagnostics and filter them however you wish, as described earlier in this topic. If you want to see the warnings differently than the default UI presents them then that is the way to do it.

Hi @apparentlymart,

It is of course your product, giving you the right to do with it as you wish.

But, can you understand that it’s a rather baffling for users to be told that a simple CLI flag merely to turn off the existing warning summarization functionality is deemed to be an overly oppressive maintenance burden, in comparison to major new features still being added to the product?

I could be wrong, but it sounds like the feature talked about here would pretty much be just 1 CLI flag and 1 if statement. For that to be too burdensome, but the new features from 1.2 and lined up for 1.3 to not be … I just don’t know how to understand that decision-making process.


+1 to the env var / cli flag addition, going through all the (deprecation) warnings one by one is an absolute and intense PITA

1 Like

By the logic expressed in this thread, it seems Terraform has reached full maturity.

The ultimate solution for new use-cases might be to switch to an alternative tool.

Quo Vadis terraform…

First you hide sensitive values without ability to show them after terraform plan that force people to use jq and other hacky way of making diff and searching what change and why, then again do changes like this to hide warnings.

Sorry but this is not the right direction for any project.

If you introduce such changes give at least ability in cli by using switches to act in old ways,
we are adults and don’t need such extra protection.