-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add validation to provider fields in both SDK and PF implementations of provider schema #9050
Add validation to provider fields in both SDK and PF implementations of provider schema #9050
Conversation
Unit tests are going to fail as I haven't updated them yet, but I wanted to push this and get some acc tests running to see if this causes any problems with VCR/acc tests |
ab01d1b
to
d48a1bf
Compare
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
6374511
to
83df041
Compare
Hi there, I'm the Modular magician. I've detected the following information about your changes: Diff reportYour PR generated some diffs in downstreams - here they are. Terraform GA: Diff ( 25 files changed, 2232 insertions(+), 123 deletions(-)) |
Tests analyticsTotal tests: Action takenFound 2 affected test(s) by replaying old test recordings. Starting RECORDING based on the most recent commit. Click here to see the affected testsTestAccProviderEmptyStrings|TestAccFolderIamPolicy_basic |
Rerun these tests in REPLAYING mode to catch issues
|
…te_service_account, project, billing_project, region, zone
…lts in a validation error, and empty provider blocks have no validation errors
d98d059
to
bcb9cad
Compare
Just rebased this branch to the recent |
The error messages can be seen in the debug logs for TestAccProviderEmptyStrings here
|
Hi there, I'm the Modular magician. I've detected the following information about your changes: Diff reportYour PR generated some diffs in downstreams - here they are. Terraform GA: Diff ( 6 files changed, 253 insertions(+), 38 deletions(-)) |
Tests analyticsTotal tests: Action takenFound 1 affected test(s) by replaying old test recordings. Starting RECORDING based on the most recent commit. Click here to see the affected testsTestAccContainerNodePool_withSandboxConfig |
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM.
Hi there, I'm the Modular magician. I've detected the following information about your changes: Diff reportYour PR generated some diffs in downstreams - here they are. Terraform GA: Diff ( 6 files changed, 253 insertions(+), 38 deletions(-)) |
Tests analyticsTotal tests: Action takenFound 3 affected test(s) by replaying old test recordings. Starting RECORDING based on the most recent commit. Click here to see the affected testsTestAccContainerNodePool_withSandboxConfig|TestAccDataprocClusterIamPolicy|TestAccDataSourceGoogleServiceAccountJwt |
Rerun these tests in REPLAYING mode to catch issues
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
99bfccd
into
FEATURE-BRANCH-major-release-5.0.0
Description
Closes hashicorp/terraform-provider-google#14447
This PR adds explicit validation feedback to users, to accompany the changes in #9014
The PR above means that
""
values will be processed by all the usual provider configuration logic but the error messages returned to users may be confusing and result in GitHub issues being opened. By adding explicit validation users will be able to identify and address the problems themselves.I've chosen to add empty string validation to the more popular fields and avoiding things like
request_reason
because I don't know if there's a valid use case for setting that value to an empty string or not?Testing
I've added:
Here's a screenshot from a manual test. NOTE: there are always 2 errors, as both the SDK and PF validators are rejecting the bad input
Misc details
Previously I thought that provider-level validation protecting against empty strings was a problem due to the SDK being weird/making it easy to footgun when handling zero values. After some manual tests I found this wasn't the case, so added anti-empty string validation to the SDK and PF versions of the provider config code.
NOTE: If validation exists on one version of the provider config but not the other then there's a fundamental error in the provider, as provider schemas must match when muxed together.
Release Note Template for Downstream PRs (will be copied)