Description
Is your feature request related to a problem?
When creating a CR, only the documentation and types are available. Sometimes the type is string and the documentation is brief or non-existent, for example for a role of type string. The api-2.json files often contains a validation pattern for this case, but the author of a CR does not have that information available, and will have to create the resource in a cluster and observe the result to check if the format is correct.
Describe the solution you'd like
Consider adding kubebuilder Pattern annotations. In order to do this we would have to expose this information in aws-sdk-for-go v1, that seems trivial:
diff -ruwbp /home/chlunde/go/pkg/mod/github.com/aws/[email protected]/private/model/api/shape.go ./private/model/api/shape.go
--- /home/chlunde/go/pkg/mod/github.com/aws/[email protected]/private/model/api/shape.go 2021-09-05 13:33:33.430030539 +0200
+++ ./private/model/api/shape.go 2021-09-05 21:59:57.401057747 +0200
@@ -80,6 +81,7 @@ type Shape struct {
MemberRef ShapeRef `json:"member"` // List ref
KeyRef ShapeRef `json:"key"` // map key ref
ValueRef ShapeRef `json:"value"` // map value ref
+ Pattern string `json:"pattern"`
Required []string
Payload string
Type stringFinally we can add it to the template, similar to
diff --git a/templates/crossplane/apis/type_def.go.tpl b/templates/crossplane/apis/type_def.go.tpl
index 6a0cbdc..4598d98 100644
--- a/templates/crossplane/apis/type_def.go.tpl
+++ b/templates/crossplane/apis/type_def.go.tpl
@@ -4,6 +4,9 @@ type {{ .Names.Camel }} struct {
{{- if $attr.Shape }}
{{ $attr.Shape.Documentation }}
{{- end }}
+ {{- if $attr.Shape.Pattern -}}
+ // +kubebuilder:validation:Pattern:={{ $attr.Shape.Pattern }}
+ {{- end }}
{{ $attr.Names.Camel }} {{ $attr.GoType }} `json:"{{ $attr.Names.CamelLower }},omitempty"`
{{- end }}
}The result
- richer validation
- documentation
- possibility of detecting errors using static checking early in gitops pipelines and development environments
- detecting errors before sending to the AWS API (if there is no static checking set up/not gitops)
Example (I have not tested this in a cluster, so the syntax might not be exactly right):
+ // +kubebuilder:validation:Pattern:=arn:(aws[a-zA-Z-]*)?:iam::\d{12}:role/?[a-zA-Z_0-9+=,.@\-_/]+
Role *string `json:"role,omitempty"`
+ // +kubebuilder:validation:Pattern:=arn:(aws[a-zA-Z0-9-]*):([a-zA-Z0-9\-])+:([a-z]{2}(-gov)?-[a-z]+-\d{1})?:(\d{12})?:(.*)
SigningJobARN *string `json:"signingJobARN,omitempty"`
+ // +kubebuilder:validation:Pattern:=arn:(aws[a-zA-Z0-9-]*):([a-zA-Z0-9\-])+:([a-z]{2}(-gov)?-[a-z]+-\d{1})?:(\d{12})?:(.*)
SigningProfileVersionARN *string `json:"signingProfileVersionARN,omitempty"`
+ // +kubebuilder:validation:Pattern:=(\$LATEST|[0-9]+)
Version *string `json:"version,omitempty"`Describe alternatives you've considered
Keeping it as it is? 🤔
Things to consider
We would also have to understand what possible differences between the regex language in the JSON files are, and what the API server validates, and possibly convert (or drop) some patterns. We should also consider if introducing validations will cause other problems, and possibly an escape hatch in generator-config.yaml to ignore the pattern for a specific attribute?
Related issue: crossplane-contrib/provider-aws#572
cc @muvaf