Open bflad opened 1 year ago
Just to capture this somewhere, it seems like some provider developers have created "debug" plan checks to deal with situations where the Terraform human-readable plan output is hiding differences, but they do show up in the machine-readable plan: https://github.com/mongodb/terraform-provider-mongodbatlas/blob/22d8c0a5da17aa52b2fc532a6900951b9a239b31/internal/testutil/acc/plan_check.go
I think there are multiple ways to interpret that sort of plan check:
I feel like options two and three could be problematic in multiple senses, which is why I hesitate to suggest them as new feature requests, such as having too much irrelevant data and potentially having subjective opinions on the output formatting. Option one makes it so developers can inspect the data without needing to copy paste the output into a file (since it will already be a file) or a website like the jq playground (unless they really want to).
Related: https://github.com/hashicorp/terraform/issues/31887
terraform-plugin-testing version
Use cases
When using the
TF_ACC_PERSIST_WORKING_DIR=1
environment variable, the directory is filled with some handy contents showing file artifacts during the testing (output assuming #114 implementation):However, looking at the plan files, they always are the last plan to occur during the test step (which is usually a plan showing no operations to verify providers aren't introducing permanent drift). It would be great to see all the plans that ran, e.g. the plan that actually created the resources in the first step or the plan updating resources in a subsequent step.
Attempted solutions
Manually look through the TRACE logging to find each plan output.
Proposal
When executing a plan and when
TF_ACC_PERSIST_WORKING_DIR
is enabled, ensure a plan file is always saved and copy the saved plan with a friendly name. Importantly, these saved plans should not be copied/persisted between steps to prevent confusion.References
113
114