Add -detailed-exitcode option to Plan

[sudomateo]

This adds the -detailed-exitcode option to tfexec.Plan() and returns
a boolean detailing whether a plan diff is empty or non-empty.

This allows the caller to make decisions when the plan has changes.

hasChanges, err := tf.Plan(context.Background())
if err != nil {
  panic(err)
}
if hasChanges {
  // Do something when the plan has changes.
}

[paultyng]

Per the internal conversation, I think we should make the following changes to surface this functionality:

• always pass -detailed-exitcode for Plan
• change the Plan function signature to Plan(...) (bool, error) where the bool represents if a diff is present or not (exit code 0 or 2)

We probably need a test case for a diff and no diff, not sure if that is present in the e2e testing yet, so probably need to add a test case that modifies the TF file, I can assist with this though if you have any questions.

[sudomateo]

@paultyng @kmoe this is ready for review. Thank you for the feedback!

[paultyng]

You probably need to confirm this is ExitError, ie something like:

Suggested change

	if err != nil && cmd.ProcessState.ExitCode() == 2 {
	var exitErr *exec.ExitError
	if errors.As(err, &exitErr) && cmd.ProcessState.ExitCode() == 2 {

[sudomateo]

I don't believe this will work since the err here is returned from parseError() (hitting the default case). At that time the original err is essentially discarded.

[sudomateo]

Should I perhaps add another case to parseError() that checks the original error and returns a new error type that I can then check from Plan()?

[paultyng]

yeah, i think we should probably fix the default case to just wrap the ExitError so that its compatible with errors.As/Is.

[paultyng]

This needs a rebase but I think we just merge it as is. The refactor for the error handling won't be user facing, so can just be a future improvement if someone gets to it.