helper/resource: compatibility refresh after config mode test step #496
Conversation
There was a problem hiding this comment.
Yeah, like we chatted about offline, if this can be a stop gap before #327 is actually resolved, I'm on board 👍🏻
Other related issues and the original change:
| // semantically-equal -- state representations in their test steps. When | ||
| // comparing two states, the testing framework is not aware of semantic | ||
| // equality or set equality, as that would rely on provider logic. | ||
| var RefreshAfterApply string |
There was a problem hiding this comment.
This acts as a build-time feature flag. The thought is that you'd add this as an ldflags value in a testacc Make target:
-X github.com/hashicorp/terraform-plugin-testing/helper/resource. RefreshAfterApply=unlocked
The ldflags bit is a weakly-held opinion. I would be receptive to using a TF_* environment variable instead.
|
|
||
| package resource | ||
|
|
||
| // Deprecated. This is an undocumented compatibility flag. When |
There was a problem hiding this comment.
Deprecated
This is about the flexibility to remove this flag some day. There is no timetable or specific urgency for that. If we get feedback that this flag is super effective & we do not come up with a better alternative in the future, then I have no desire to break it 😃
Background: #269
This change is intended to unlock an upgrade path from
v1.5.1to latestv1.13.1.When
RefreshAfterApplyis set to non-empty via a build flag, aConfig-mode test step will invoke a refresh before successful completion. This is intended as a compatibility measure for test cases that have different -- but semantically-equal -- state representations in their test steps. When comparing two states, the testing framework is not aware of semantic equality or set equality, as that would rely on provider logic.A
Config-mode test step that is followed by aRefresh-mode test step will not incur an extra refresh. This is a backward-compatible way for a provider to eventually remove the compatibility flag – existing tests can be updated to explicitly refresh, incrementally.cc: @BBBmau: I'd definitely like to get feedback from the provider team before shipping this. And it would be helpful to try this on a feature branch & see if it introduces any test failures.