Optional flag to treat warnings as errors

[oeuftete]

Terraform Version

Terraform v1.3.5
on darwin_amd64

Use Cases

As an engineer using terraform, I want the option to get forceful feedback from terraform, particularly with CI, when deprecated usages are introduced (e.g. through provider upgrades, old copypasta, etc.). Warning text at the end of a successful plan is easily missed -- again, particularly when using CI.

Attempted Solutions

None, although some form of output parsing post-plan would be a CI workaround.

Proposal

Add a CLI option to terraform plan that supports treating warnings as errors. At a minimum, it would set a non-zero exit code if any warnings are present during an otherwise successful plan. It might also update the yellow Warning: text to red Error: text, though for my purposes that is less important.

  -warnings-as-errors All warnings produces by Terraform are upgraded to errors
                      in plan output and will set the Errored exit status.

References

• A request to optionally make a particular warning an error: https://github.com/hashicorp/terraform/issues/31280. Opener did suggest a similar overall option in a followup comment.
• Old identical request possibly ignored since it didn't use a template (fair enough!): https://github.com/hashicorp/terraform/issues/23411

[crw]

Thanks for this request!

[vromanocarepay]

Any news here?

[crw]

No updates to report.

If you are viewing this issue and would like to indicate your interest, please use the 👍 reaction on the issue description to upvote this issue. We also welcome additional use case descriptions. Thanks again!

[mloskot]

We also welcome additional use case descriptions.

A quite obvious one, warnings as errors treatment would help to hard stop at the check block assert-s failure in order to actually prevent Terraform from continuing operation execution.

[juan-vg]

A quite obvious one, warnings as errors treatment would help to hard stop at the check block assert-s failure in order to actually prevent Terraform from continuing operation execution.

While I agree with this, I still believe that the check block should allow to specify whether the behaviour should be to produce a warning or an error. I mean, that's a behaviour that the check should choose based on the kind of check. I would not like to have to rely on plan parameters, but to define the behaviour for each check. This will also allow to define & combine checks for warnings and errors in the same plan.

[danielskowronski]

Would it make sense to treat this as an opportunity to improve warnings experience in TF CLI by broadening the scope of the issue by:

1. making it possible to filter warnings - so instead of all (which I believe would quickly become problematic even in the best CI/CD) to have something similar to what Terragrunt exposes for retriable errors
2. letting user choose the behaviour - I see the rationale behind elevating the status of a given warning to an error that stops execution, but at the same time, sometimes you want to ignore certain warnings (users will do it anyway, we should at least give them possibility to do it cleanly)

My suggestion would be impossible to implement within normal source code (like proposed check blocks). However, it could be added to .terraformrc.