Describe the need

From #2903

Problem:
We keep getting impacted by Error: Invalid provider configuration resulting from the various ways the provider checks and creates secrets.

This particular issue has plagued our last few deployments and it originated from a very old PR being introduced and released which changed how we handle secrets.

We have about 4 different implementations, that exist in 6 different resources, of how we handle secrets scoped to specific areas. These various implementations have made it difficult to determining what is idiomatic for this provider given it's been done differently in the resources here:

resource_github_actions_environment_secret.go resource_github_actions_secret.go resource_github_actions_organization_secret.go resource_github_dependabot_organization_secret.go resource_github_codespaces_organization_secret.go resource_github_codespaces_user_secret.go 

The destroy_on_drift pattern is problematic at best - its unpredictable, does not fit our idioms, and the detection is unreliable.

Some of our implementations have Update functions + ForceNew (which are causing InternalValidate errors), some perform recreation ForceNew , some have internalized logic into destroy_on_drift , not to mention that there are different field evaluations and configurations across resources.

@stevehipwell tossed out the idea around having a "secret version field" - that approach seems to fit the provider well and it would let us rip out the convoluted conditional logic around setting and unsetting fields as well as be much more deterministic. This field would control when the secret value is updated and would give user's far more control.

SDK Version

v6.8.3

API Version

No response

Relevant log output

Code of Conduct

• I agree to follow this project's Code of Conduct