terraform test: allow computed/mocked values override during planning

[dsa0x]

Fixes #35851

This PR enables users to use mocked or overridden values when running a plan command. The attribute override_during can be set to plan or apply. This attribute can be set in the blocks for override_*, and mock_provider.

Target Release

1.11.0

Draft CHANGELOG entry

NEW FEATURES | UPGRADE NOTES | ENHANCEMENTS | BUG FIXES | EXPERIMENTS

[liamcervante]

I think the implementation looks good, just not super happy with the chosen name. I'd be interested to know your thoughts!

[liamcervante]

We have the command attribute available in the run blocks: https://developer.hashicorp.com/terraform/language/tests#run-blocks

I wonder if like compute_command that maps to a keyword of either plan or apply might be more clear about what is happening here? We can make it default to apply.

I think that makes it a bit more clear about what the attribute is actually doing. What do you think?

[dsa0x]

Thanks for the suggestion. I contemplated quite a bit on the right name to communicate what's going on here, and you are right that override_computed seems a bit unclear. However, I have similar thoughts about compute_command, especially the compute part. That may be confusing. What about override_command/override_target/override_target_command = plan/apply? From a user POV, they have defined the override, and want it to be applied. That it is a computed attribute is more subtle.

[liamcervante]

I like override_command, I think that could work. Another idea I had was override_during - as an attribute it doesn't make much sense on it's own, but when coupled with apply or plan then it brings a lot of context eg. override_during = plan.

But, override_command is also good I think 👍

[liamcervante]

Sorry, I just noticed a couple of places where you have pointers and I don't think you need them. This doesn't affect the behaviour of anything though, but I think makes every thing look a bit neater.

Also, since we just merged the changes to the CHANGELOG process you should add a CHANGELOG entry in this PR now.

[liamcervante]

sorry, I didn't notice this before - I don't think this needs to be a pointer. You can just make it a normal bool, and public so callers can read it directly.

We don't need to distinguish between "not set" and explicitly set to false right?

[liamcervante]

I think you could also make this return a string without a pointer -> just return "apply" if the attribute isn't set.

[dsa0x]

In this section internal/configs/mock_provider.go#L317-L325, the field needs to be a pointer. This is necessary because, if the override_* block does not explicitly set a value for override_during, the global value should be applied. However, if the override_* block does set a value, it should take precedence over the global value. Using a pointer allows us to differentiate between an explicitly set value and a zero value.

[liamcervante]

ah nice! Makes sense!

[liamcervante]

ah nice! Makes sense!

[liamcervante]

There's a lot of commits here, so I'd make sure to squash and merge this - you might do that be default already but just wanted to make sure.

[github-actions]

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions.
If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.