-
Notifications
You must be signed in to change notification settings - Fork 232
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 a warning/error option to schema validation #745
base: main
Are you sure you want to change the base?
Conversation
Here's some output from testing, in case it helps. I copied the My only issue with it is that it repeats the messages quite a lot. But I wasn't able to find the cause of this redundancy.
Here's the full provider schema where I'm using |
helper/schema/schema.go
Outdated
// When set to WARNING, a warning message is displayed to the user. | ||
// When set to ERROR (default), a fatal error is returned. | ||
// Optionally, a message can be returned with the warning or error. | ||
ConditionsMode string |
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.
Is there any chance we could make this an enum with constants, rather than a string?
E.g.:
type SchemaConditionsMode uint8
const (
SchemaConditionsModeError SchemaConditionsMode = 0
SchemaConditionsModeWarning SchemaConditionsMode = 1
)
Then in this Schema struct it would be:
type Schema struct {
// everything else is the same, omitting
ConditionsMode SchemaConditionsMode
// everything else is the same, omitting
}
and in when using it, you'd do:
mySchema := &schema.Schema{
// everything else is the same, omitting
ConditionsMode: schema.SchemaConditionsModeWarning,
// everything else is the same, omitting
}
This has the neat benefit that we can define the default behavior (unset/0) as SchemaConditionsModeError
, meaning we don't need to detect when it's unset, the default is just an error.
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.
Alternatively, we could make ConditionsMode
accept a diag.Severity
, but I think I like that less.
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.
Wow, that is really neat! Sure, I'll try this.
helper/schema/schema_test.go
Outdated
|
||
Config: map[string]interface{}{ | ||
"whitelist": "white-val", | ||
"blacklist": "black-val", |
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.
nitpick: can we use "allowlist" and "denylist" or something similar?
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.
(I'm sure you're just copying code that exists, but I'd like to leave the campsite better than we found it and not carry that pattern into the future. :) )
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.
I would prefer this too! Would it be ok if I replace this in other tests too? Or should I limit the scope of my changes for this PR? (For reference, there are 144 instances of "whitelist" in this file).
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.
As long as the tests pass, I would be happy to accept that change as part of this PR, in the spirit of leaving the area of code we're working on better than we found it, as we're unlikely to prioritize a PR that changed only those things. :)
Add new schema options to configure the warning/error level of validation functions. This allows the following functions to be used as a warning-level diag instead of a fatal error: "ConflictsWith", "AtLeastOneOf", "ExactlyOneOf", "RequiredWith". The ConditionsMode allows provider developers to toggle between "warning" and "error" level messages. The ConditionsMessage is an optional additional message to be displayed to users at run time.
I rebased, added the enum type, and updated the tests. Tests are passing.
I also made the required changes in the Kubernetes provider PR, to test the new type there. It worked when I tested it in minikube. |
@@ -1452,19 +1469,19 @@ func (m schemaMap) validate( | |||
err := validateExactlyOneAttribute(k, schema, c) | |||
if err != nil { | |||
return append(diags, diag.Diagnostic{ | |||
Severity: diag.Error, | |||
Severity: diag.Severity(schema.ConditionsMode), |
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.
Sorry to nitpick, but I'd feel much better about explicitly converting these rather than type casting, because if either value ever changes, I think the results would be surprising.
Maybe we could have a SchemaConditionsMode.AsDiagSeverity
method that returned the diag.Severity
for that mode? The method could be as simple as:
func (s SchemaConditionsMode) AsDiagSeverity() diag.Severity {
switch s {
case SchemaConditionsModeWarning:
return diag.Warning
default:
return diag.Error
}
}
for example.
Add new schema options to configure the warning/error level of validation functions.
This allows the following functions to be used as a warning-level diag instead of a fatal error:
"ConflictsWith", "AtLeastOneOf", "ExactlyOneOf", "RequiredWith".
The ConditionsMode allows provider developers to toggle between "warning" and "error" level messages.
The ConditionsMessage is an optional additional message to be displayed to users at run time.
Fixes #727.