add detailed-exitcode-ish behavior with saved plan file

[StephenWithPH]

Current Terraform Version

Terraform v0.12.3

Use-cases

When running Terraform in automation per official guidance with human approval between plan and apply, a saved plan is always generated. If the saved plan is a no-op, it would be useful to be able to determine that fact using only the saved plan in later automation stages. This would allow build stages which either wait for human plan approval or run apply on the saved plan to exit early.

Attempted Solutions

1. terraform plan can be invoked with -detailed-exitcode and -out=<path> to both create a plan file and communicate whether there's work to be done. User-provided convenience scripts in the build step can respond accordingly, but many build systems have limitations when trying to communicate between different steps/stages/jobs in the larger workflow/graph/pipeline. Collapsing -detailed-exitcode's 1 = Error and 2 = Succeeded with non-empty diff (changes present) exit codes into the usual "any non-zero exit code is a failure" on the build ends up masking useful feedback ("plan failed" versus "plan shows work to do"). Doing so also forces the rest of the workflow/graph/pipeilne down a "failure" path, which is a bit abusive if trying simply to omit the terraform applystep when appropriate.
2. terraform show -json ./tfplan | jq '...' seems possible to back into this, but using jq to parse the plan json to determine if there's work to be done is... gross. The user's jq filter may become a source of bugs in the workflow/graph/pipeline logic.

Proposal

(either/or)

• enhance terraform plan to take an optional path to an existing plan file and allow the existing -detailed-exitcode flag to accurately reflect the state of the provided plan file
• enhance terraform show to take an optional -detailed-exitcode flag to accurately reflect the state of the provided plan file

References

• https://learn.hashicorp.com/terraform/development/running-terraform-in-automation

[danieldreier]

@StephenWithPH this is an interesting suggestion and the workflow you're describing makes sense to me. For clarification, is this something you're hoping to build and you're filing this to coordinate prior to making a pull request, or are you asking the terraform core team to make this improvement?

[StephenWithPH]

@danieldreier ... thank you for the quick response!

For clarification, is this something you're hoping to build and you're filing this to coordinate prior to making a pull request, or are you asking the terraform core team to make this improvement?

I can't honestly commit to finding the time to implement this and PR it myself. I would love it if the Terraform Core team gets to it, but I'm happy to see this wait and (hopefully) accrue enough 👍 to merit Core team efforts.

[danieldreier]

Thanks @StephenWithPH! This isn't going to be a short-term priority for us, but I think it's a solid idea. If someone wants to build it, please put your ✋up and we should design it a little more together. This is a solid area for work, but we'll want to spec it out a little more before work starts to make sure we don't make breaking changes to exit codes. If anyone is interested, please say so. In the meantime, I'm going to put this in our backlog and we'll prioritize based on interest and engineering availability.