helper/resource: compatibility refresh after config mode test step #496
Conversation
helper/resource/compatibility.go
Outdated
|
|
||
| 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 😃
@BBBmau: I'm sorry for my delay in replying. I've now updated this branch to use a new environment variable: Would you update & give this one more run with your provider's suite for confidence before we release? |
|
@bbasata did some 2 nightly runs to confirm that things are good with the environment variable! We can go ahead with the release when you're ready. |
| // If the next step is a refresh, then we have no need to refresh here | ||
| if !c.Steps[stepIndex+1].RefreshState { | ||
| // Echo a searchable message to easily determine when this is no longer being used | ||
| fmt.Println(EnvTfAccRefreshAfterApply+":", "running apply -refresh-only -refresh=true") |
There was a problem hiding this comment.
nit: We should probably use the logging package for this with whatever log level you think is appropriate
Done
and done! |
) (#538) * experimental: refresh after config mode test step * fixup! experimental: refresh after config mode test step * Skip an unnecessary refresh * Rename compatibility flag and extract to compatibility.go * Add header * Use an environment variable * logging > fmt * Add changelog entry
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.