Skip to content
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 option to disable kubebuilder markers #555

Merged
merged 1 commit into from
Jun 14, 2024

Conversation

arianaw66
Copy link
Contributor

@arianaw66 arianaw66 commented Jun 14, 2024

Description

Adds option to disable kubebuilder markers and validations to omit them from the generated OpenAPI schema.

Changes can be seen in-action here

Context

This is needed for https://github.com/solo-io/gloo-mesh-enterprise/issues/17005

When disableKubeMarkers is set to true, Type=object annotations will be respected such that recursive fields will still work. Required annotations will also be respected.

This is essentially a cherry-pick of solo-io/skv2#567.

@solo-changelog-bot
Copy link

Issues linked to changelog:
https://github.com/solo-io/gloo-mesh-enterprise/issues/17005

@soloio-bulldozer soloio-bulldozer bot merged commit ecc4f32 into main Jun 14, 2024
3 checks passed
@soloio-bulldozer soloio-bulldozer bot deleted the disable-kube-markers branch June 14, 2024 18:24
Copy link
Contributor

@sam-heilbron sam-heilbron left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice work!

Makefile Show resolved Hide resolved
@@ -32,7 +32,7 @@ require (
github.com/solo-io/go-utils v0.24.8
github.com/solo-io/k8s-utils v0.7.2
github.com/solo-io/protoc-gen-ext v0.0.18
github.com/solo-io/protoc-gen-openapi v0.1.1
github.com/solo-io/protoc-gen-openapi v0.2.4
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: When bumping libraries across minor versions, I tend to callout in the PR body what those changes were. Mostly just to get in the habit of validating changes, because we have noticed that sometimes there are behavioral change that impact us. Since this is an internal library that we manage, and is low risk, it's certainly not a requirement (more sharing as it's a pattern I follow)

@@ -105,10 +109,11 @@ func (o *OpenApiProtocExecutor) Execute(protoFile string, toFile string, imports
_ = os.Mkdir(directoryPath, os.ModePerm)

cmd.Args = append(cmd.Args,
fmt.Sprintf("--openapi_out=yaml=true,single_file=false,include_description=%v,enum_as_int_or_string=%v,additional_empty_schema=%v:%s",
fmt.Sprintf("--openapi_out=yaml=true,single_file=false,include_description=%v,enum_as_int_or_string=%v,additional_empty_schema=%v,disable_kube_markers=%v:%s",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this change, because it follows the precedent that existed. An alternative way to perhaps improve this "API" would be to just expose a raw string to users. This string would be passed from callers of the code, down to protoc. This way, the next time we add an argument to our open-api protoc impelementation, we don't need to pipe through values, and can instead just update the string

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I prefer that to exposing a clear option in solo-kit that IDEs won't let you typo and such, but certainly a conversation we can have.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants